>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> i disagree with the two classes. how can you handle an unexpected event >> without know it could happen? effectively all events are expected, some >> are more expected than others. :) DS> The terminology there's a bit strained, and I think it's in large part DS> responsible for most of the rest of the confusion. that seems to be the case. do an edit pass with better names and clearer definitions. DS> They're probably better called Named and Anonymous events, though DS> that's a bit dodgy in some ways too. Maybe specific and generic events DS> would be better. DS> The basic difference is that with Named events you *know* in advance DS> that the event is coming because you explicitly requested it by DS> setting a timer or making an IO request. (A specific timer or IO DS> request, not timer or IO requests in general) This is different from DS> things like signals as you've not asked for a particular signal to DS> fire--they fire off whenever something outside your control and DS> expectation happens. ok. now signals are not normally 'handled' by any code (c included) unless you specify something. so all events at that level are always specified. if parrot needs to handle signals even when no user code asked to handle them, then i can see a need for this separation. but it should only be used for internal parrot stuff and all other events should be specified at the user level. i see no reason for any user code (PASM and up) to not do a proper handler specification. DS> Because of this, you have the event PMC for a Named event before the DS> event occurs and thus can wait on it. You *don't* have the event PMC DS> for an anonymous event, so you can't wait on it, all you can do is DS> semi-generically react once it's occurred. i think that should read "all parrot can do is react, assuming it is the one that set the signal handler (at the c/kernel level)". DS> Callbacks and User Data DS> ======================= >> DS> Each expected event can have a callback routine and piece of user DS> data associated with it. When the event request is satisfied (The IO DS> operation completes or the timer fires, for example) the callback DS> associated with it is invoked. The user data, as well as the event DS> data, if there is any, is passed into the callback. >> >> the event handle(r) itself also is passed to the callback. DS> No, it isn't. i think i meant the event itself. the handler is what is called in the callback. >> you say event >> data there and maybe you mean event structure/object? DS> Nope, I mean event data. It's the data that whatever triggered the DS> event generated. then those terms need to be cleanly defined. user data is passed into the event and passed back to the callback. it is meant for the user code to associate an event with some user state. it can be an object/structure/id//whatever. the event data is the actual data returned by the event iself from the event source. it will contain data read from an file/socket or mouse coords/stuff or signal information, etc. DS> Callback signatures are fixed, and of the form: >> DS> (Preturndata, Icommandstatus) = DS> callbacksub(Pevent, Peventdata, Puserdata, Icommand) >> DS> The callback is passed in the event PMC, the PMC for the event data, DS> and the PMC for the user data, if any. (Either or both of these can DS> be the Null PMC if there is no user or event data) Command is always DS> 0 for callback handling. (Callbacks and IO layer functions are DS> identical. More detail in the IO section) >> >> how about renaming userdata to iodata since that is what it >> is. DS> It isn't though. The event data is the IO data here. ok, i can work with your name choices as long as they are clearly defined. >> huh? if you are in an event handler, you have seen the event (and are >> presumably in user level code), so why would you wait for it again? DS> You're confused here. The event handler is what throws the DS> exception. It's the user code that's waited on the event that gets the DS> exception. (And it's possible, though likely a bad idea, to have an DS> exception handler make an async request and wait for it to complete) i am confused everywhere! :) the OP says this: DS> With an expected event, if an event handler is terminated by an DS> unhandled exception, that exception is attached to the event itself, DS> and when user-level code C<wait>s on the event, the exception is DS> thrown then. you have to be in an event handler to terminate it. so you must have waited for it or be in a callback. so why would you need to wait for it again after it terminated because of an exception? you are in user code space now so let the exception system do its thing (like you said). if it isn't caught, do the normal thing. i don't see why the event needs to be tagged with the exception. if it wasn't handled in the (already called) handler environment why would another wait be any better? my point is that an event handler IS user level code. all the event system does is monitor the actual events, queue the triggered ones and dispatch to handlers via callbacks. the handlers and exception handling is all user space above that. >> you also can use a 'stopped/disabled' state. in many cases you want >> an active event but stopped for a while. DS> That can't happen. You can cancel an event, but that's it. You can DS> stop an event source, but that's different. that is bad IMO. why do you need the entire overhead of creation/destruction of an event just to stop it temporarily? this buffered async write scenario is common and very useful. it is so much easier and faster to just stop/start the existing event instead of creating/cancelling a new one each time the writer needs to fire up. this can be done easily for normal i/o events with a flag which makes the select/poll loop skip it. if you are going to do blocking reads/writes in individual kernal threads for this, then it will be harder or impossible. you could still dedicate one thread to handle all simple i/o event requests and have it run a select/poll loop for them all. then when it gets a triggered event, it does the same queueing of it that you want to do now. this way you save on threads, allow for stop/start and still can use other kernel threads for special event stuff that won't always work well with event loops (signals for one). >> add enable/disable here. DS> Nope. Events aren't enable-able/disable-able. can you explain why not? >> i don't think there is a need for all those variants. why would alarm >> need any special opcode when it is just a timer with a delay of abs_time >> - NOW? let the coder handle that and lose the extra op codes. DS> I didn't see any reason to not do absolute times as well as DS> deltas. It's no big deal either way. >> also the interval can be folded in as a extra arg to the timer (either a >> repeat flag or an interval). the initial seconds can be the first delay >> and then reused for intervals or the interval value can take over: >> >> settimer Pevent, Idelay_seconds, Iinterval_seconds[, Pcallback, >> Puserdata] >> >> if interval_seconds is set (>0), use it for a repeating timer. if >> delay_seconds is set (>0), it is the first interval. DS> Ick. No. It's not like there's any less code there, and the intent's a DS> bit clearer. but a combination of the two still has one nice feature. you can have the initial delay be X and the interval afterwards be Y. not a deal breaker and easily done with a wrapper but i like it. :) DS> INTVAL Parrot_ping_event(Parrot_Interp Interpreter, INTVAL type); >> DS> Note that an event of type C<type> has just occurred. Returns either DS> 0 on success or 1 on failure. This function may fail if the target DS> interpreter is unable to post an event to its event queue. This DS> normally happens because there are no event PMCs available to DS> allocate for the event. >> >> clarify. who 'notes'? DS> Posts an event of the specified type to the event queue of the target DS> interpreter. >> maybe call it 'check_event'? how is this different >> than post_event? DS> No PMC handling. It means that whatever code's doing it doesn't have DS> to manage a PMC queue (since if it's in an interrupt handler it can't DS> allocate one--they need to be preallocated) and set up all the bits of DS> the event PMC. Of limited utility, but for things like signal handlers DS> that can't do much anyway and have so little information available to DS> them it's sufficient. ok, so ping is a lightweight post? the spec should say something like that mixed with your comments. 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
