It was my understanding that a session would stay alive as long as it has child sessions. Did that behavior change?
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. -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
