>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> 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.
DS> I suppose, but for that I'd go with registering a callback to issue a DS> write for read requests and a read for write requests, and make things DS> specific.
but then you still need the main line of code to block/wait on something such as select or a reading an event from a blocking socket.
Or just issue a generic process_events op and spin through the events in the event queue forevermore. :)
DS> I can't think of a sufficiently good reason you'd want to, say, DS> pause the program waiting specifically for a SIGINT, but I'm open DS> to ideas. (And this can be deferred, since it'd be straightforward DS> enough 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.
DS> As can I, but I'm not sure it's the right thing to do. (And I'm not DS> sure what should happen with callbacks in that situation either--do DS> they go off as well, or not?)
if you set the callbacks, they should be triggered. but if you do a wait on a SIG, you most likely wouldn't also set callbacks for it.
Well... that's where I'm not sure, since it has the potential of really screwing up library code, much the same way that a "join any done thread" can do so. Imagine, for example, waiting on a generic timer event--you wouldn't know for sure if it was yours, and if you didn't run the callback for it you'd likely mess up whatever the library code was doing.
DS> I was going to go with a single data element. Callbacks have a DS> signature like:
DS> callbacksub(event handle, custom data)
DS> with the assumption that if you've more than one thing to pass in you DS> build up a structure or array or something. Keeps things relatively DS> simple, as well as manageable from C code.
at this level that makes sense. at the higher levels it is cleaner to provide the direct id field and the other main thing is an object. wrapping an object and an id in a higher level thing makes calling the object harder.
Yeah, but... objects. They ought to be hard. Really! :-P -- Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
