>>>>> "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. sometimes a specific wait will simplify things if you only have one pending event. sure, for more events, callbacks are a win. and a callback system implies a need for some wait/select/run_loop blocking op. otherwise the rest of the code will run forever and occassionally get interrupted by a callback. 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. 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. in parrot you would pass in a structure which had the object, the method, and the id (and more?). but that wrapper layer has to handle generic callbacks and then redispatch to the actual object with the higher level api. actually i did such an event wrapper which does similar things (it adds id and timers and such) to lower level event layers. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
