Joshua N Pritikin wrote: >Because merely calling asynccheck never eliminates the race condition. >It just makes it "shorter."
It does eliminate the race condition, in that it makes ->pending return a list of pending events that was correct at some point during ->pending's execution. Also, the type of situation I've got in my program, blocking signals, means that there is no race condition anyway -- no new signals can arrive while ->pending is executing. >No, they aren't reified events until you run asynccheck. Yes, that's the problem. I'm arguing that they should be fully reified whenever the reified events are examined. > This is the >same as io events. You don't know if a socket has data to read until >you call poll/select. I/O and idle events already behave differently from signal events. I/O and idle watchers are watching for a condition which at any moment is present or absent, whereas signal watchers are watching for instantaneous events. It is appropriate for the two classes of event to behave differently. >1. signal watcher->start >2. decide to stop the signal watcher >2a. sigblock >2b. sweep >3. signal watcher->stop() sweep() will execute event handlers, will it not? I don't want to do that. -zefram
