IRC would be the place to be, but like the list, there are a lot of
lurkers. Better chances of getting a hold of Rocco's (a.k.a. dngor)
ear though on IRC
On 8/21/06, Mathieu Longtin <[EMAIL PROTECTED]> wrote:
I'm with you on the wait_for_signal.
However, I note that there is very little traffic on this
mailing list, not even a announcement of the last two POE
release.
So, I wonder if POE discussions are all on some other
mailing list, or stritly on IRC at this point.
-Mathieu
--- Nick Williams <[EMAIL PROTECTED]> 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
> >>
> >>
> >>
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
