Re: pending signal events

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAiKCcqcqnlKSmC70RAmzsAKCg5un3wYY/6MbPMvicNOxkpWCxTwCffnse
7dHEEBYr1W9I7EQ0O6hpYh8=
=mMWv
-----END PGP SIGNATURE-----