On Tue, Dec 04, 2001 at 01:44:17PM -0700, Chris Fedde wrote:
> On Tue, 4 Dec 2001 15:21:03 -0500 Rocco Caputo wrote:
> +------------------
> | Either way, each session needs some code to gracefully shut itself
> | down. Using signals, that code would be tied to the fictitious
> | GO_AWAY_NOW signal:
> |
> | POE::Session->create(
> | inline_states => {
> | _start => \&start_the_peace_process,
> | ...,
> | my_personal_shutdown_event => \&halt_the_peace_process,
> | }
> | );
> +------------------
>
> You'd recommend using a new event rather than doing it in the _stop event?
Yes. _stop isn't meant to initiate a shutdown; it only lets sessions
know they're about to be garbage collected. "No, Lieutenant, your
Session is already dead."
My plan was to add a new event that initiates shutdown and broadcast
that as a signal(). Once the shutdown has released its resources
(turned off timers, deleted wheels, removed aliases, etc.), its
reference counters drop to zero, and POE::Kernel stops it.
Oh, and to abuse $kernel->signal() to broadcast that event everywhere.
Shutting down "keep alive" resources from _stop is usually unnecessary
since the entire HEAP will be destroyed when _stop's handler returns.
The only time you really need to manage HEAP in _stop is when it holds
circular references or things that don't have DESTROY methods to clean
themselves up.
If you still just want to kill all your sessions with extreme
prejudice, you can broadcast a terminal signal (one which defaults to
killing a process, like SIGKILL) instead of GO_AWAY_NOW. Sessions
that don't handle this class of signals will go directly to the _stop
state, not passing Go! and not collecting 200 events.
POE::Kernel will then clear out the session's alarms, events, aliases,
and other things.
Also see:
http://poe.perl.org/?POE_FAQ/How_do_I_force_a_session_to_shut_down
http://poe.perl.org/?POE_FAQ/Why_do_my_sessions_not_stop_on_their_own
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
