>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> However...
DS> There are those pesky repeating events, and events from outside DS> sources. Signals, mouse clicks, window resizes, repeating timer DS> firings... stuff like that. Can anyone think of a reason that someone DS> would want to wait *specifically* on one type of event like this, DS> enough to warrant fetching (and creating, and doing synchronizing DS> stuff on) the handle for it?
sure. a simple double buffering stream program. it starts an async read and waits for it. when ready starts another read in the other buffer, it mungs the data in the first buffer and does an async write out (say, to a socket) but doesn't wait. then it waits on the second read. so this does specific waits on handles and nothing else.
I suppose, but for that I'd go with registering a callback to issue a write for read requests and a read for write requests, and make things specific.
DS> I can't think of a sufficiently good reason you'd want to, say, pause DS> the program waiting specifically for a SIGINT, but I'm open to DS> ideas. (And this can be deferred, since it'd be straightforward enough DS> to add this later with no disruption to the design)
a program could go completely to sleep waiting on a signal and then wake up when it gets the signal. i can see a use for that.
As can I, but I'm not sure it's the right thing to do. (And I'm not sure what should happen with callbacks in that situation either--do they go off as well, or not?)
DS> Note that this is completely separate from callbacks and data for DS> events--regardless of what we do here you'll still be able to register DS> a callback sub for each event type and a data element to be passed DS> into it along with the event itself.
that sounds good too. we need both api's. and i can see the need for 2 data elements (i am using that now).
I was going to go with a single data element. Callbacks have a signature like:
callbacksub(event handle, custom data)
with the assumption that if you've more than one thing to pass in you build up a structure or array or something. Keeps things relatively simple, as well as manageable from C code.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
