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
