>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Or just issue a generic process_events op and spin through the events DS> in the event queue forevermore. :) i love spinning the cpu. idle loops are your friend! :) >> 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> Well... that's where I'm not sure, since it has the potential of DS> really screwing up library code, much the same way that a "join any DS> done thread" can do so. Imagine, for example, waiting on a generic DS> timer event--you wouldn't know for sure if it was yours, and if you DS> didn't run the callback for it you'd likely mess up whatever the DS> library code was doing. i was thinking that the signal was the only outstanding event there. the whole process goes dormant blocking/waiting for the signal. when it arrives, the wait call returns and the process wakes up and takes over the earth. kinda like waiting for the SIGGODOT. :) again, i would want such a blocking wait only for that simple case. with multiple events, you can deal with specific waits if designed cleanly but multiple waits (which is really select) is of course better in complex apps. 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. DS> Yeah, but... objects. They ought to be hard. Really! :-P not in my event world! :) writing a multi-listen socket server with time delayed responses and custom response code in only 4 subs/callbacks is my event world. :) i want parrot to have such a nice event api that it will heavily influence the p6 event api. 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
