On Thu, Apr 29, 2004 at 05:16:22PM +0100, Zefram wrote: > What really needs to be done with the Event API is not necessarily to > get the cleanest handling of async events but to make it possible to > handle them somehow. The API just doesn't permit these events to be > handled properly. If you are implacably opposed to making async events > invisible, then you must provide a way to explicitly invoke asynccheck, > so that it is possible to handle them correctly in cases where race > conditions can be ruled out. As an Event user I'd be satisfied with that.
Yah, so what about making Event::_queue_pending() a public API? > >Event has its faults, but it _is_ optimized for speed. > > Are ->start and ->pending really speed-critical? I find that unlikely. > Optimising for speed means optimising the things that get called the most, > *not* absolutely everything. asynccheck itself is cheap. > > Do you have timing tests you can run to try out my proposed changes? It's not a matter of knowing whether ->start is speed-critical. AsychCheck is only called when it is unavoidable. That's the rule. So to follow the rule and insure a clean and consistent API, we can't add random calls to AsycnCheck in various places. See, I'm using the "clean and consistent" argument to justify the current design while you are using the same argument against the current design. Isn't this terribly tricky? ;-) > >asyncCheck is only called where we can't avoid it, in one_event (and > >sweep). > > Another approach: calling asynccheck when it's theoretically required can > be *optional*, allowing the user to make the tradeoff between cleanliness > and speed. The default should be to perform asyncchecks automatically, > so that if the user does nothing special it all works, giving a really > clean interface. If the user wants to get that little bit of extra speed, > they can explicitly choose to accept the extra complication of having to > be aware of when asynccheck runs. There would be an option on ->pending, > ->start, one_event, sweep, and loop, to say "don't bother checking for > async events"; it should also be possible to invoke asynccheck explicitly. OK, but how would the implementation actually work? I don't want to add more conditional branches within the inner loop (one_event). -- A new cognitive theory of emotion, http://openheartlogic.org
signature.asc
Description: Digital signature
