Reply To: Interrupt handling and SoEMT

Caution: work in progress. The RTS is coming up, but is not supporting multithreading yet.

Currently the interrupt mechanism is factored out from the multithreading mechanism; while an interrupt can be delivered to an explicit core (and a trap or fault is always delivered to the core that encountered the event), the handler always runs in the thread that was interrupted in that core. That handler may in turn activate other threads of course.

When we get further in the kernel implementation, and have sim numbers for realistic code, then the idea of decorating a handler dispatch with a thread id to dispatch may prove to be advantageous. We simply don’t know yet. One factor that might force such a design is if there are quanta problems in servicing interrupts in app threads. However, currently we are thinking that quanta will be associated with turfs and not with processes, so an interrupt, which typically will portal to a different turf, won’t run using the interruptee’s quanta.

We are reasonably confident that the current sim mechanism for external interrupts is incomplete, because there isn’t one 🙂 We do model internal events though, and I/O that is instigated by the core. The architecture admits arbitrary interrupting of interrupts arbitrarily deeply, so in principle there is no need for priority in accepting the interrupt itself; priority dispersion would occur when the handler enabled a thread and yielded the core. Of course, that assumes that the handler will be relatively short-lived and well behaved.

We do have RPC well defined, albeit not yet working in the RTS. That is intra-core RPC though; intercore RPC is as yet as ill-defined as other forms of interrupt.

Sorry I can’t me more informative; we’ll have much better answers when the guts of the kernel are done.