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. 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. Is there any hope for rethinking the desire to expose the ugliness of Unix signals in the Parrot VM? - Damien