On Mon, Apr 26, 2004 at 10:58:06PM +0100, Zefram wrote: > Joshua N Pritikin wrote: > >Yah, OK, but is there a real-world justification for running > >asynccheck when creating signal watchers? Or is this just a > >theoretical cleanliness argument? > > I haven't thought up a specific example where one would want to have > two watchers for the same signal and start them at different times. > I invented the case in the abstract form, from thinking about the > structure of the code. My argument for changing this behaviour is > simply to make Event provide its documented interface exactly, in all > cases, so that calling code can actually rely on it. My experience has > consistently been that abstractly-predicted awkward cases eventually > do turn up for real, usually in a completely unexpected way. There is > thus a significant practical benefit from keeping interfaces clean and > implementations meticulously correct, a benefit that is lost by the > slightest cutting of any corners.
Sure, but is Event really the perfect API design that we should try to implement perfectly? That would be an interesting discussion! What does Event do wrong and what would a better design look like ... ? Anyway, > You seem to object to the slight extra complication of the code? It only > need be a couple of lines, and ->start is not performance-critical. > It seems strange to ccompromise on correctness for such minor > considerations, even if one does not consider complete correctness to > be an important consideration. > > More thoughts on the theory of async events: async events need to be > reified whenever it is necessary to distinguish between events before > and after the present moment. ->start is such an occasion, because the > new watcher must see events that occur after its creation but not those > that occur before. ->pending also is, because it should return a complete > list of the events that have been seen so far. ->stop, actually, is not: > with pending events being cancelled, unhandled events occurring before > stop and those occurring immediately afterwards have the same behaviour > (they are not handled by the watcher). Event has its faults, but it _is_ optimized for speed. My general rule for async events is that polling for them is usually a waste of time (statistically speaking, how many calls to asyncCheck actually find new events for a long-running server? 0.001%?). Therefore, asyncCheck is only called where we can't avoid it, in one_event (and sweep). So the moral of this story is: what looks clean and tiddy from one angle might look as an untidy mess from another angle. It's almost enough to make me throw up my hands is despair. Surely you know that I offered to give up maintainership of Event? Nobody took my offer. ;-) > Incidentally, it would be useful for the theory of events to be made > explicit in the documentation. I'm happy to write it up myself, > regardless of how this debate turns out. Yah sure, but it would be more productive to write a design document which improves upon Event's design. -- A new cognitive theory of emotion, http://openheartlogic.org
signature.asc
Description: Digital signature
