The way things are going to work with specific actions a program has asked to be done, such as a disk read or write, is that you get back a handle PMC that represents the request, and you can wait on that handle for the request to be completed. The sequence goes something like:
write Px, Py, Sz # Return handle, file, and data to write
waitfor Px # Wait for the request to finishand that all works out nicely. Each async request returns a handle for that request, and you can wait on it, check it for done-ness, get its status, or try and cancel it. Generally good. (As well as trivially easy to wrap with synchrony for programs that don't want the headaches that async IO brings)
However...
There are those pesky repeating events, and events from outside sources. Signals, mouse clicks, window resizes, repeating timer firings... stuff like that. Can anyone think of a reason that someone would want to wait *specifically* on one type of event like this, enough to warrant fetching (and creating, and doing synchronizing stuff on) the handle for it?
I can't think of a sufficiently good reason you'd want to, say, pause the program waiting specifically for a SIGINT, but I'm open to ideas. (And this can be deferred, since it'd be straightforward enough to add this later with no disruption to the design)
Note that this is completely separate from callbacks and data for events--regardless of what we do here you'll still be able to register a callback sub for each event type and a data element to be passed into it along with the event itself.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
