Events are notice of something happening (though different from notficications, which are separate, I think). IO was complete, signals pinged, timers fired, whatever. Something happened.
Events should be checked and processed in several instances:
1) When a blocking IO op is being performed. All IO is async, so a blocking request is really a "queue IO request and drain event queue until notice of completion is returned"
2) When the queue is explicitly drained. A draineventqueueforever op, or something much like it
3) When we do a quick check to see if there are pending events to be processed
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. It's been suggested that a "checkevent" keyword get added to the signature of ops that should check for events as part of their processing, which isn't a bad idea either.
So the deal is that everything that generates events throws an entry in the event queue, and the interpreter as it runs grabs events out of the queue when it chooses and processes the events.
We still need to talk about event records, callbacks, what blocks what, and privilege issues with events, which we ought to get out of the way now.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
