4

What changes need to be made to a language/runtime if one wants to implement fully asynchronous exceptions (thrown from one thread to another, capable of interrupting pure computation without the need for polling)? What issues and challenges need to be addressed and how? What would be the difference in implementation between compiled, JIT-ed and interpreted languages?

Martin
  • 149
  • 4
  • What would be the semantics of such exceptions? What would the thread throwing the exception do? Wait for an answer from the receiver of the exception? How would the receiver thread react? Interrupt any work it was doing in order to handle the exception? Or would it be supposed to be an idle thread whose only purpose is handle exceptions? What would be the use / advantage of asynchronous exceptions? – Giorgio Nov 20 '16 at 19:27
  • @Giorgio precisely, .... I've tried to ask the broader questions, but I've been [shot down](http://softwareengineering.stackexchange.com/questions/336399/are-there-language-environments-with-asynchronous-exceptions), maybe I just don't know how to ask right,... anyhoo ... the way I see it, the throwing thread throws and forgets, the receiving thread behaves as if a rethrow appeared at the point of interruption, some outer function would catch it. It can be used e.g. to interrupt a long running calculation. .... having an idle thread for this is the same as a inter-thread message passing. – Martin Nov 20 '16 at 19:44

1 Answers1

2

Well, that's basically what interrupts are at the OS/interprocess level.

For a multithreaded environment, your main challenge will be making it work with mutex mechanisms used to prevent race conditions in shared memory.

My intuition is that this will prove to be impossible.

It could work with environments that don't have shared memory between threads, like Erlang.

Michael Borgwardt
  • 51,037
  • 13
  • 124
  • 176
  • 1
    Or with other higher-level concurrency mechanisms like Futures/Promises. Surely this problem has already been solved at the OS/Interprocess level. – Robert Harvey Nov 20 '16 at 19:48
  • @RobertHarvey can the Future/Promise model be interrupted without polling? "stop calculating NOW" instead of "while(!should_stop){do_a_little();}" – Martin Nov 20 '16 at 20:03
  • @RobertHarvey: No, as far as I can tell, at the interprocess level the "solution" is to either just disable interrupts while executing critical sections, or to make the interrupt handler explicitly handle any data corruption that might have happened because it was called. – Michael Borgwardt Nov 20 '16 at 21:26
  • @MichaelBorgwardt what kinds of race conditions do you expect to encounter in addition to the ones already occurring in MT programs? I mean, what new problems are being added. – Martin Nov 21 '16 at 08:59
  • @Martin: Interrupts work without polling at the hardware level, but the price is that your code is stopped in the middle of whatever it was doing, so e.g. it could leave some data structure half-intialized and thus in an inconsistent state. And you'd have the thread holding locks intended to prevent other threads from seeing that inconsistent state. If you just release the locks, you have corrupted data, if you keep them you have a deadlock. – Michael Borgwardt Nov 21 '16 at 11:26
  • @MichaelBorgwardt when you say interrupts, do you mean posix signals? .... what about relying on exception propagation and RAII to release locks held by some kind of handle? Do you think that would fix this? – Martin Nov 21 '16 at 12:15
  • @Martin: yeah, my terminology was unclear, though signals and hardware interrupts are related. RAII could ensure the locks are released properly, but how about half-finished operations? The cleanup code would have to know what's the previous consistent state. You'd end up having some kind of transaction mechanism for in-memory operations... yeah, it could probably be made to work, but it would require new programming idioms and probably a lot of effort. – Michael Borgwardt Nov 21 '16 at 12:45
  • @MichaelBorgwardt how would this be different from what stack unwinding does for normal exceptions? – Martin Nov 21 '16 at 13:00
  • @Martin: stack unwinding won't help you with inconsistent heap data. – Michael Borgwardt Nov 21 '16 at 13:18
  • @MichaelBorgwardt why not? stack unwinding is calling destructurs, and it handles situations like an exception thrown in the middle of a constructor, and if it can apply the destructor to the subset of already constructed objects, why couldn't a similar mechanism determine what needs to be done or undone in case of an exception at every single point in a program? I don't see how this leads to inconsistent heap state, what am I missing? – Martin Nov 21 '16 at 13:34