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
