On 22-Oct-2001 Bob Maccione wrote:
> (!!!) Posted events now keep sessions alive. This simplifies
> inter-session communication greatly, eliminating the need to call()
> between sessions. Chances are that this won't break many (any?)
> programs, but it's flagged as such to catch your attention.
>
>
> I have a question on the above. It probably answers a problem I've been
> tracking.
>
> When a session disconnects from POE, it should throw the _stop event (or
> call the _stop callback). At least that is what I'm seeing.
>
> What 'cleanup' should be done to ensure that that session and any
> events/alarms/etc are cleanly destroyed? Currently I'm doing a:
>
> delete $_[HEAP]->{readwrite};
>
> however this isn't getting any alarms that may be still pending.
If you are in a _stop event, all alarms, handles, wheels and so on have
already been cleaned up. _stop is just a very last "go away" state.
If you want an event that explicitly kills a session, you create an event
called 'shutdown' (or anything else). Then explicitly post it. You then
put all clean up code in there.
sub shutdown
{
my($kernel, $session, $heap)=@_[KERNEL, SESSION, HEAP];
# delete all wheels.
delete $heap->{wheel};
# clear your alias
$kernel->alias_remove($heap->{alias});
# clear all alarms you might have set
foreach my $alarms (keys %{$heap->{alarms}}) {
$kernel->alarm_remove($alarms);
}
delete $heap->{alarms};
# get rid of external ref count
$kernel->refcount_decrement($session, 'my ref name');
# propagate the message to children
$kernel->post($heap->{child_session}, 'shutdown');
# Rocco : is there a way of getting at what the kernel knows about
# a session's children?
return;
}
Hmm... This should go into the FAQ!
-Philip
