Joshua N Pritikin wrote: >Ick. That's probably a bug. What I'm going to do is just drop any >pending signals when you can stop(). Will that work for you?
Interesting. ->stop is actually documented to cancel pending events; I hadn't noticed that before. So that change does seem to be necessary, on the theory that the signals that have been only counted are actually pending events. It will solve this issue for my program, thanks. >> 0. (bug) ->pending() should do an asynccheck > >That changes the documented behavior too much. How so? The same theory that says ->stop should cancel these signal events says that ->pending should return them as event objects. 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. -zefram
