How are asynchronous exception implemented?

Question

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?

• Giorgio: 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?
• Martin: @Giorgio precisely, .... I've tried to ask the broader questions, but I've been shot down, 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.

Answer 1

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.

• Robert Harvey: Or with other higher-level concurrency mechanisms like Futures/Promises. Surely this problem has already been solved at the OS/Interprocess level.
• Martin: @RobertHarvey can the Future/Promise model be interrupted without polling? "stop calculating NOW" instead of "while(!should_stop){do_a_little();}"
• Michael Borgwardt: @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.
• Martin: @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.
• Michael Borgwardt: @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.