On Thu, Apr 22, 2004 at 08:16:43AM +0100, Zefram wrote: > Joshua N Pritikin wrote: > >> 0. (bug) ->pending() should do an asynccheck > > > >That changes the documented behavior too much. > > How so?
Because merely calling asynccheck never eliminates the race condition. It just makes it "shorter." > The same theory that says ->stop should cancel these signal > events says that ->pending should return them as event objects. No, they aren't reified events until you run asynccheck. This is the same as io events. You don't know if a socket has data to read until you call poll/select. > I see asynccheck (and any other handling of async events, such as > the ->stop magic you've added) as invisible glue; it should be done > wherever necessary to pretend that the async events that have been > received are real pending events in the event queue. If they are > consistently treated as if they were, then promoting them to event > objects is invisible from the point of view of the documented interface. > It's exactly that invisibility that would be achieved by making ->pending > perform promotions. Well sure, but explain how to do that without race conditions. At least with yesterday's patch, you can count your signals accurately. For example: 1. signal watcher->start 2. decide to stop the signal watcher 2a. sigblock 2b. sweep 3. signal watcher->stop() -- A new cognitive theory of emotion, http://openheartlogic.org
signature.asc
Description: Digital signature
