Esteemed Monks,

I am searching for a way to catch and handle a Control-C when using multiple POE sessions. I have successfully used the snippet from the POE Cookbook to actually catch the INT signal in each of my Sessions:

inline_states => {
    _connected  => sub {
        my ($kernel, $session) = @_[KERNEL, SESSION];

        ## Handle control-C
        $kernel->sig( INT => 'event_sigint' );

        ...

} # inline_states

...

        event_sigint => sub {
            my ($kernel, $session) = @_[KERNEL, SESSION];
            print STDERR "Caught Control-C, shutting down gracefully.\
+n"; 
            $kernel->yield("Shutdown",2,'Received break from user');
        }, # event_sigint
[download]

In all but one of my sessions I simply catch the signal and print to STDERR a simple message giving the session alias. The above snippet is in only one of my sessions and I want to use it to do the graceful shutdown.

However, I am using POE::Component::SimpleDBI, which uses POE::Wheel::Run to fork a child process that does the 'heavy-lifting' as the POD puts it. What is happening is that somewhere in POE's reaping of the child process(es) created by POE::Component::SimpleDBI, the POE kernel itself is (or seems to be) stopping in its tracks.

Things I have tried:

#1 - manually adding an INT handler to SimpleDBI.pm
#2 - perusing kernel.pm and signals.pm for clues

I confess to the monks that this challenge is beyond me and I humbly submit the question for your review: is there a way to have POE reap the child process without dying immediately thereafter, allowing me to yield a shutdown subroutine to do the cleanup and exit?

Many thanks,

-MC