>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The way things are going to work with specific actions a program has DS> asked to be done, such as a disk read or write, is that you get back a DS> handle PMC that represents the request, and you can wait on that DS> handle for the request to be completed. The sequence goes something DS> like: DS> write Px, Py, Sz # Return handle, file, and data to write DS> waitfor Px # Wait for the request to finish DS> and that all works out nicely. Each async request returns a handle for DS> that request, and you can wait on it, check it for done-ness, get its DS> status, or try and cancel it. Generally good. (As well as trivially DS> easy to wrap with synchrony for programs that don't want the headaches DS> that async IO brings) i like that. just like RT-11 had (READ, READW and READC :) 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. 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. but the coder can emulate waiting on a single event with a wait_for_any_event (with infinite timeout and/or looping wrapper) provided there is only one event outstanding. but a simpler api (which could just implement the looping wrapper with infinite/long timeout) would be useful. 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). the prime element is an object which gets a callback via a method (and the method name should also be an argument with a default name) and a second data element is an 'id' thing. the reason is that one object could have multiple instances of the same type of event and the id is used to differentiate them. you could have unique method callbacks for each object but that is ugly when you have many of them. a table of these objects keyed by the id is much cleaner as they would share a single method. the main element (the object or class) is required if you want a callback and the id is optional (but always passed back to callbacks even if not set). a poor workaround for the id is to use the event handle itself as the unique id but that means the handle/id is not meant for printing and makes it harder to debug. a string id can be used to tie multiple event and related things in the object together while a handle id is tied to the single event. i have running p5 code which uses this style of callback api if anyone wants to see it. it supports all you need in callbacks with a clean 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
