On Fri, Jul 18, 2003 at 11:29:27AM -0400, Dan Sugalski wrote:
> Nope, that won't work. A lot of what's done is really "main thread
> with interrupts" and that doesn't map well to doing all signal
> handling in separate threads. You really do want to pause the main
> program to handle the events that are coming in, if they're events of
> sufficient importance. Generally I put them in three classes--hard
> interrupts (signals), soft interrupts (IO completion stuff), and
> events (fuzzy user-level stuff). Hard and soft interrupts should get
> dealt with as soon as possible, events should probably wait until
> something explicitly decides to process an event.
In my experience, interrupt handlers in Perl code generally fall
into three categories: Ones that set a flag to be checked later,
ones that perform an action and terminate the program, and buggy
ones subject to race conditions.
IO completion events in particular should not be handled by
interrupting the main execution thread. The appropriate action
required to handle these events will almost invariably require
access to data structures shared between the interrrupt handler
and the main thread. If you place the interrupt handler in the
main thread, you can't use locks to control access to these
structures (as the handler will wait on the main thread's lock,
while the main thread will block on the handler returning).
This leads to Unix-style signal masks, where interrupts are
blocked during critical sections. While this works, I strongly
feel that a platform with thread support is better off dispatching
interrupts to a separate thread and using the existing interthread
synchronization mechanisms, rather than introducing a separate
interrupt masking system.
Also, given that asynchronous IO is a fairly unpopular programming
technique these days (non-blocking event-loop IO and blocking
threaded IO are far more common), I would think long and hard before
placing support for it as a core design goal of the VM. If there
is a compelling reason to use AIO, the implementation may better
be handled at a lower level than Parrot; even if Parrot itself does
not support AIO at the opcode level, Parrot programs could still
use it by calling down to a C library.
> It's not just signals, there's a lot of stuff that falls into this
> category. We've got to deal with it, and deal with it properly, since
> not dealing with it gets you an 80% solution.
Outside of signals and AIO, what requires async event dispatch?
User events, as you pointed out above, are better handled through
an explicit request for the next event.
- Damien
