On Aug 22, 2006, at 14:06, Nick Williams wrote:
Rocco Caputo wrote:
Do you have a use case where it's impossible to do something
under the new behavior? I'm working under the assumption that a
session can always find a way to call sig(YOUR_SIGNAL_HERE =>
undef) when it's ready to be destroyed.
"When it's ready to be destroyed" is the key. The new behaviour
means that sessions need to track that themselves and (in effect)
manage their own reference counting independent of POE's. Before,
they could just rely on POE to let them know via _stop. Now, _stop
is no longer called unless the session clears the sig first. This
is just a catch-22. And it leaves a race condition whereby the
session exists but has declared it no longer wants the signal.
Sessions already do need to manage their reference counts, at least
in the sense that they won't exit until they stop watching for
events. Signal events are just another kind of event, and the
semantics were a bit exceptional for some good reasons that don't
necessarily apply anymore.
If I understand the catch-22 correctly, it's that a session can't
clear its signal watchers from _stop because those watchers prevent
_stop from executing. If that's the case, I'd like to point out that
it's not very useful to clear any resources from _stop to begin
with. POE will automatically reclaim its resources from the session
after _stop returns, so any explicit POE cleanup in _stop is an
expensive no-op.
To be fair regarding discussions on this list, Jonathan Steinert
announced the intent to make sig() hold sessions alive in his 19
October 2005 message titled "Nastiness, and wrapping up signal
reforms". I replied that day with:
Big change. I don't mind this; the old semantics of not holding
a reference count were tied to _signal, which delivered signals
without sessions explicitly asking for them. _signal is gone
now, so we can tie the explicit interest of sig() into a
reference count to keep the session alive.
Nobody else responded. 17 days later I replied with a public go-
ahead to make the change.
Yes, I realise that there was this discussion previously. However,
speaking purely for myself, I didn't understand the impact of this
at the time, since I wasn't cognizant of the internals of session
reference counting at the time. Now I've looked at this, and I
can't see how the new implementation makes sense.
I can understand how the implementation might be confusing. The
released versions since last December have flaws, especially
regarding reference counting. In fact I recently committed fixes for
them while portability testing some of Benjamin Smith's new tests.
My issue is that that the bugzilla that Jonathan was attempting to
fix is just trivial to fix using existing POE mechanisms of
aliases, since there's an easy point at which you know you want to
start the persistence of the session, and there's a well-defined
point at which you can release the persistence. However, by making
the behaviour of persistence implicit within signals, there is
simply no way to achieve the opposite effect (automatic garbage
collection). The user (the application) must decide at which point
it has no more work to do and at that point it can then clear the
signal. And only then will POE do it's garbage collection and call
back to the application. This just doesn't make sense. Especially
when you compare signals in POE with signals in other dispatchers.
Having a handler configured for a signal should not make that
process persistent.
The point that persistence shouldn't be tied to signals for
flexibility's sake is the start of a slippery slope. What would then
stop us from asserting that some timers should not imply
persistence? Input timeouts, for example. They don't contribute to
a session's lifespan since they're only relevant as long as there's
an I/O watcher. Why then should delay() keep sessions alive?
One solution might be to expand the Kernel's APIs for different
semantic variants of each watcher. The endgame for that strategy is
ugly at best. Another solution might be to drop implicit reference
counting altogether. Every session would then need to explicitly
hold something as long as it wanted to live. That's the "alias"
idea, although it should probably be something with a stronger
reference count. Then there's the converse: No session will die
unless it explicitly asks to be killed. Each has a certain charm,
although both have their pitfalls.
I think none of the solutions in the previous paragraph will satisfy
a significant portion of POE's users, so I'd rather just not go there
at this point.
Your last point is a good one. Where possible, POE has used Unix as
a model for its behavior, and signal handlers don't contribute to a
process' lifetime. The new sig() semantics are therefore incongruous
with the base model. Before I trash them, though, I'd like to learn
more about the other side. Are the new sig() semantics necessary? I
seem to recall yes, but I don't remember the details. If Jonathan
Steinert doesn't explain it, I'll need to make time to grovel through
my logs (and the source) to refresh my memory.
And it's after 04.30 here (it's the only time I could make to answer
this message). I'm not committing to anything until after some sleep.
Maybe I'm thinking about it wrong. To me, "explicit interest of sig
()" does not mean to me that I (this session) want to stay around
until that sig, it means to me that it's merely putting in place a
handler IN CASE of that sig. It's a really really important
distinction. With the huge differentiator that the latter behaviour
of 'in-case-of-handlers' CANNOT be achieved in the new POE signal
world without careful application coding and ignoring any of the
benefits of POE's internal garbage collection.
As a compromise, I've also proposed implicitly that maybe we should
have a new function wait_for_sig() as well as just sig(), so that
we can make the difference in semantics explicit to users. I don't
mind which way around the functions and semantics are achieved, so
long as there is a way of doing this.
People can interpret it either way depending on requirements and
point of view. In the past I've had to explain why sig(USR1 =>
"event") won't keep a daemon alive.
I'm still opposed to methods for semantic variants, though. I'd
rather avoid having both semantics at once if that's possible.
--
Rocco Caputo - [EMAIL PROTECTED]
