I dont use signals all that much or POE, but I thought Id put in my 2 cents.
IMO, signals should mirror UNIX signals - they dont keep a session alive. I
hear that this can cause problems with certain signals, so someone suggested
adding a sig() that keeps a session alive. Rocco didnt like having two
method calls for slightly different semantics.
Perhaps we could fall in the middle: sig() doesnt keep a session alive
UNLESS you ask it to. sig( SIGNAL = 'state' ) doesnt keep a session
alive, but sig( SIGNAL = 'state', -keepalive ) would.
Theres two sides to this fence, and only implementing one side is going to
make the other unhappy. Straddling the fence isnt desireable, but it looks
to be the best option.
Another thing I did think of recently is that only signals that require to
keep a session alive keep them alive. DIE, TERM, USR1, etc wouldnt keep a
session alive, but the ones that need to ( UI_DESTROY was mentioned in this
case ) would keep a session alive.
PS. Sorry if that sounds like a bunch of rambling.
On 8/23/06, Nick Williams [EMAIL PROTECTED] wrote:
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
