On Tue, Jul 27, 2004 at 11:54:47AM +0000, Ton Hospel wrote:
> Consider the following code:
>
> #!/usr/bin/perl -wl
> use Event;
> use POE;
> pipe(my $read, my $write) || die "pipe: $!";
> close $write;
> POE::Session->create(inline_states => {
> _start => sub { $poe_kernel->select_read($read, "readable") },
> readable => sub { $poe_kernel->select_read($read); die "Aaargh" }
> });
>
> $poe_kernel->run;
>
> It will set up a readability event which directly triggers. In the
> "readable" state the event is removed, and then the code dies.
> The builtin Event eval will catch it, and give an error. Now POE will
> reenter it's event loop, but there are no more sources, so it just sits
> there.
>
> All other POE loops I tested (Select, Poll and Tk) don't have this
> problem, they crash more or less cleanly out of the main loop.
>
> While I realize that "die" is not a very proper thing to use, i think the
> wait without eventsources is not the right reaction.
> (I also don't know why the underlying Event.pm event loop doesn't just
> quit. It's supposed to do that if there are no more sources, but using
> strace I can see it sitting there with a poll() with nothing in it).
>
> used: POE version 0.28_08, Event version 1.00, perl version 5.8.4
Event discusses this under "Customization and Exceptions". Its
default exception handler continues the main loop after something
dies.
I've replaced Event's default exception handler with one that reads
sub _our_event_exception_handler {
my ($event, $message) = @_;
warn $message;
exit 1;
}
and set this inside loop_initialize()
$Event::DIED = \&_our_event_exception_handler;
It's the best I can do on short notice. Calling die() within the
exception handler just triggers a new, recursive message, and prevents
the event loop from exiting. Even setting $SIG{__DIE__} = "DEFAULT"
didn't help.
--
Rocco Caputo - http://poe.perl.org/
