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. 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). 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. -zefram
