On Aug 23, 2006, at 13:58, Nick Williams wrote:
>11:05 @ dngor : Requiring interest in a signal to be
registered explicitly is a relatively new advancement. Now that we
have it, I don't see why not.
>11:25 @ hachi : well, I think it might have to happen, at
least in the case of a CHLD handler, because you can't have that
signal watcher dying off silently on people
I *guess* that the signal watcher logic is only invoked if there's
someone interested in SIGCHLD. If there's nobody interested in
SIGCHLD, then the default behaviour can work just fine. Is that
true? And then the follow-on is that if someone was previously
interested in SIGHCHLD and then they say they're not, what happens?
If the signal handler reverts back to normal perl semantics, then I
don't see a problem with the signal watcher no longer spinning. So,
I can't quite see how this adds up to requiring persistent
sessions. I feel very much that I'm missing some understanding here
of how the SIGCHLD stuff has been done. I'll go away and read code
while waiting for others to correct me :-)
POE's SIGCHLD handler reverts back to $SIG{CHLD} = "DEFAULT" when the
last watcher is turned off.
I will experimentally remove the signal handler reference counts to
verify that the accompanying signal changes won't be broken. The
results will probably not be ready for the next release, which is
instead focusing on the tests Benjamin Smith wrote during Google's
Summer of Code. I need to finish testing and porting his tests to
multiple systems before they can be released.
Does anyone prefer that signal handlers keep sessions alive? This is
your opportunity to explain why. I don't want sig()'s semantics
flapping back and forth, so a reversion will most likely be permanent.
--
Rocco Caputo - [EMAIL PROTECTED]
