On Thu, Jul 17, 2003 at 12:58:12PM -0400, Dan Sugalski wrote:The first is done in the case of readw or writew, for example. The second for event-driven programs that set up callbacks and park themselves forever in one big ProcessEvent call. (Tk programs come to mind) The third is to be scattered in generated code to make sure that events are occasionally checked for, and will probably drain only high-priority events and at most a single low-priorty event.
While it's possibly politically impossible (many people are very attached to Unix signals), I'd really rather work with a system that does async event dispatch exclusively through threads. Interrupting a thread in the middle of its execution and sending it haring off to an interrupt handler is not only clumsy and difficut to implement, it's a recipe for buggy code.
We're not doing the traditional C-style interrupt. That's infeasable at the level we operate at generally, so we're not. We *are* simulating it, since potentially some of Parrot's instructions will be 'interruptable' or check interrupts, or whatever you want to call it. (I call it annoying but necessary :)
Much nicer would be if events were always dispatched in one of two ways:
- Synchronously, by calling a GetNextEvent or ProcessEvent function.
- Asynchronously, by spawning a new thread and executing the signal
handler within it.
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.
Is there any hope for rethinking the desire to expose the ugliness of Unix signals in the Parrot VM?
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.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
