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.
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.
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.
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.
Nick
