3 ms·

> Take cancellation for example: cancelling tasks under the synchronous programming model requires passing a context object through every part of your code that

> Take cancellation for example: cancelling tasks under the synchronous programming model requires passing a context object through every part of your code that might call down into an IO operation. Does it? Wouldn’t you just kill the thread in the synchronous model?

meindnoch 2y ago
That's a sure way to get leaks and deadlocks.
- scotty79 2y ago
  Can you have leaks when everything is garbage collected? Do deadlocks occur if killable threads aren't allowed to wait for other threads?
  - pjc50 2y ago
    You can probably make this work if and only if the thread is shared-nothing. If you share any data structure with another thread then you have the possibility of leaving it in an invalid state when killed. This also requires any "channel" primitives you use for inter-thread communication to be tolerant of either thread being killed at any instruction boundary, which is hard to design.
    - meindnoch 2y ago
      Shared-nothing threads? So basically processes.
  - meindnoch 2y ago
    Java threads were killable originally. Then it turned out to be impossible to use safely, so it got deprecated: https://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html https://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadP...
pjc50 2y ago
Killing threads uncooperatively wrecks all your other concurrency primitives. Not a theoretical consideration, for example we recently discovered that with GRPC Java if you kill a thread while it is making a request, it will leave the channel object in an unusable state for all other threads.
ikekkdcjkfke 2y ago
Cancellation is just a boolean that is checked between smaller increments of the full job
mike_hearn 2y ago
You'd interrupt it using something like Java's interrupt model. That doesn't require any context object (the Thread is itself the context) and works correctly with (synchronous) I/O operations. The big problem with InterruptedException is that it's checked, and developers often don't know what to do with it so tend to swallow it or retry. There isn't necessarily a solid discipline about how to handle interruption in every library. But that is of course an orthogonal problem that you'd have with any sufficiently pervasive cancellation scheme.
munch117 2y ago
Anything that makes cancellation decisions from the outside of a black box is unsound. You are asking the programmer of the thing being cancelled to program in such a way, that the impact on the world outside abides by all invariants no matter where the cancellation happens. For threads, that an impossible ask. Thread cancellation is a big no-no. Just never do that. Sibling's mention of leaks and deadlocks are just examples of things that can go wrong. Task cancellation in async has the same issues. Less so, maybe much less so, because every space between two awaits acts as a no-cancellation-zone, but it's still a very suspect thing to do.

meindnoch 2y ago

That's a sure way to get leaks and deadlocks.

scotty79 2y ago
Can you have leaks when everything is garbage collected? Do deadlocks occur if killable threads aren't allowed to wait for other threads?
- pjc50 2y ago
  You can probably make this work if and only if the thread is shared-nothing. If you share any data structure with another thread then you have the possibility of leaving it in an invalid state when killed. This also requires any "channel" primitives you use for inter-thread communication to be tolerant of either thread being killed at any instruction boundary, which is hard to design.
  - meindnoch 2y ago
    Shared-nothing threads? So basically processes.
- meindnoch 2y ago
  Java threads were killable originally. Then it turned out to be impossible to use safely, so it got deprecated: https://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html https://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadP...

pjc50 2y ago

Killing threads uncooperatively wrecks all your other concurrency primitives. Not a theoretical consideration, for example we recently discovered that with GRPC Java if you kill a thread while it is making a request, it will leave the channel object in an unusable state for all other threads.

ikekkdcjkfke 2y ago

Cancellation is just a boolean that is checked between smaller increments of the full job

mike_hearn 2y ago

You'd interrupt it using something like Java's interrupt model. That doesn't require any context object (the Thread is itself the context) and works correctly with (synchronous) I/O operations. The big problem with InterruptedException is that it's checked, and developers often don't know what to do with it so tend to swallow it or retry. There isn't necessarily a solid discipline about how to handle interruption in every library. But that is of course an orthogonal problem that you'd have with any sufficiently pervasive cancellation scheme.

munch117 2y ago

Anything that makes cancellation decisions from the outside of a black box is unsound. You are asking the programmer of the thing being cancelled to program in such a way, that the impact on the world outside abides by all invariants no matter where the cancellation happens. For threads, that an impossible ask. Thread cancellation is a big no-no. Just never do that. Sibling's mention of leaks and deadlocks are just examples of things that can go wrong. Task cancellation in async has the same issues. Less so, maybe much less so, because every space between two awaits acts as a no-cancellation-zone, but it's still a very suspect thing to do.