Rocco Caputo wrote:
Attached as a gzipped text file. Sorry for posting a "binary", but I
couldn't pass up the 3:1 compression. Please quote relevant parts of
the discussion if you want to comment on things. Total time to cull
and clean this, about 90 minutes.
I hope it explains the motivations and reasoning behind the sig()
semantics change. Armed with the full context, we might be able to
come up with a better and lasting resolution to the signals problems.
Regarding SIGCHLD, I think Philip Gwyn later suggested some form of
process ID watcher to supplant the signal. I don't think he proposed
it on the list, though.
Gosh, thanks for spending that time and providing the discussion, it's
quite a fair amount of reading and most valuable :-).
To my mind, the initial part of the discussion regarding SIGCHLD is
completely orthogonal to the later problem discussed of reference
counts. I'm fine with the way that the SIGHCHLD discussion turned out
(and btw, in case anyone cares, I'm one of those people that was bitten
by system() and qx() going wrong when using POE - the reason being that
I don't just use POE, I sometimes (shock horror) use OTHER perl modules
too. One doesn't always have control of what those other modules might
be doing in their depths and system() is one of those things...) :-). We
have some systems written with POE that use over 200 different modules.
Tracking downstream modules for their use of system() is just not feasible.
So, the SIGCHLD part good. Now let's move onto the reference counting.
The discussion implies that the reference counting is neccessary for the
SIGCHILD reform. Now that's the bit that's confusing me.
>10:13 @ hachi : shouldn't a signal handler keep any session
alive, no matter what?
>10:44 @ dngor : Signal handlers don't affect reference counts.
>11:01 @ hachi : now that has me puzzled
>11:02 @ hachi : signal handlers are IPC, like filehandles... why
don't they keep sessions alive?
That's a misnomer. A handler isn't an IPC like a filehandle. As has been
said previously, if you look at UNIX semantics, signals are very very
different. And BTW, the "ultimate" example of this is the DIE handler.
If I put in place a DIE handler, it's because of defensive programming
(all those external 200 modules :-): I do not EXPECT nor WANT a DIE to
actually happen. However, if I put in place a DIE handler, my session
becomes persistent. And there's a possible race condition with me
removing the DIE handler when I *think* my session is going to die (but
hasn't yet reached _stop, and so could quite easily still get a DIE) and
the session really evaporating.
>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
So, that last comment is one of the spurs for putting in reference
counting. I've been misled by reading the RT stuff saying that the
refcounting was there for the UI_DESTROY problem. Okay. So....
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 :-)
Nick
