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
>
