Its not impossible, its just more trouble to terminate a
session. POE suffers from poor huffman encoding as it is,
adding more obligatory code to do simple things makes it
worse. Now I have to put a line to register the signal, one
to deregister it, and a "stop" state, just to make sure I
deregister the signal, and I have to make sure all
terminating states yield to "stop" instead of just not
yielding when terminating.
Except for the UI_DESTROYED, how many signals do sessions
really wait for before terminating, as opposed to using
them informationaly?
Maybe have a call to stop the current session:
$KERNEL->stop_session()
The session stops, no question asked, lose all the aliases,
all the signals, all the postback/callback become invalid,
etc... and _stop gets called, not necessarily in that
order.
-Mathieu
--- Rocco Caputo <[EMAIL PROTECTED]> 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.
>
> 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?
> >>>>
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
