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.
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.
--
Rocco Caputo - [EMAIL PROTECTED]
On Aug 21, 2006, at 09:58, Nick Williams wrote:
There appears to be a lack of opinion on this issue. Would it be
therefore reasonable to backout the signal change in POE? Or can
anyone suggest a way around the problem?
Nick.
[EMAIL PROTECTED] wrote:
On Wed, 2 Aug 2006, Mathieu Longtin wrote:
It was my understanding that a session would stay alive as
long as it has child sessions. Did that behavior change?
No, this is not down to a child session - AFAIK, the behaviour
there has
not changed.
I'm in agreement with Nick here. If a session is stritly
waiting for a child session to finish, then have it call
waitpid.
$_[KERNEL]->wait_for_child($session, "state", @args);
wait_for_child would add a link back to the current
session, the same way set_delay does.
The issue is not wait_for_child, it's wait_for_signal (which doesn't
exist). The original problem report was that people were confused by
setting up a signal handler for UIDESTROY didn't make the session
persistent. That is standard signal semantics and the persistence
could've easily been changed by using aliases.
The new behaviour in POE (as of .3202) is that when placing a signal
handler on a session, e.g.
$kernel->sig('uidestroy', 'do_something');
that will now increment the reference count of the session and
therefore
make that session persistent until the signal handler is deleted via
something (and note, not within the _stop event, since we don't
get that
far).
Nick.
-Mathieu
--- Nick Williams <[EMAIL PROTECTED]> wrote:
So, I've found the reason that recent releases of POE
cause me to get
memory leaks - I know others have had problems also, so I
wanted to get
an open discussion of what I'm being bitten by and
possible ways to
workaround this.
It turns out for me that my sessions aren't being garbage
collected. In
general, my POE system doesn't *require* the _stop event
to be processed
and so I never noticed this. However, peeking into the
system shows a
large number of sessions and I can see that none of the
_stop events
have been called.
This is because of the change:
2005-11-07 06:59:07 (r1852) by hachi
poe/lib/POE/Resource/Signals.pm M;
poe/lib/POE/Resource/Sessions.pm M
Change signal watchers so they keep sessions
alive.
WARNING: This is a major semantics change in POE.
It has the
potential to make code 'hang' in places where it
formerly did not.
This change is necessary so sessions expressing
an interest in SIG
CH?LD do not die prematurely. (There is a planned
mandatory warning
for reaped children that were not being watched.)
This change fixes
RT 15215.
The problem with this change is that if I set up a signal
handler for
something innocuous (e.g. to handle DIE, or one of my
hand-rolled
signals), this means that the session will do everything
appropriately
except be garbage collected. I think the intention of
this change is
reasonable, but to make it the default behavior for all
possible signals
is a bit keen. If I put in place a handler for a signal,
it does NOT
mean that I want to WAIT for the signal, it usually means
that the
signal shouldn't even happen, but that I'm putting in
place a handler
*in-case* it happens. It certainly shouldn't make my
session persistent!
I'm not sure of "the best way" of fixing this. Possibly
enhancing the
API to have an explicity waitforsig() and maybesig()?
(That's half
tongue-in-cheek, but is actually one of the better
solutions). In terms
of "normal" API, a sig handler shouldn't block, so I
would expect the
sig() behaviour to follow that paradigm...
Thoughts, anyone?
Nick
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
