Handle Signal and Wrap Up

Question:
I've got a program that builds a FIFO stack. I'm trying to handle any interrupt signals (CTRL-C and such, and possibly orders from the O/S to terminate) by trapping the signal, finishing off the particular element in the stack, and then exiting.

I'm aware of the %SIG hash:

$SIG{INT} = \&handler;

sub handler {
    our $int++;
    die "signaled";
}
[download]

However, I'm not sure how to manage this stack problem and I've no idea where to start.

Suggestions?

dsb
This @ISA my( $cool ) %SIG

Comment on Handle Signal and Wrap Up Download Code
Re: Handle Signal and Wrap Up by aukjan (Friar) on Aug 19, 2005 at 13:53 UTC
It all depends on what you mean by finishing off the particular element. Do you mean that you are processing an element and now the program is interrupted, but you still want to continue with the same process?? This could be very dangerous, and should only be attemted if you know exactly where your program was when it was intterrupted. This means that you will have to keep track of every step in the processing of that element. Please explain more clearly what your intentions are. And how you process your elements. Go Fish!	[reply]
Re^2: Handle Signal and Wrap Up by dsb (Chaplain) on Aug 19, 2005 at 14:27 UTC
Sorry for being vague. What I mean is that if the program is in the middle of processing the 3rd element in the stack and it receives an interrupt signal, I'd like it to finish the 3rd element and ONLY the third element before it exits. I don't want it to continue processing past that point. The processing is such that the element is `shift()`ed off the stack (duh), then sent to a function that will print to a log file, and send the element to a package for processing via DBI and DBD::ODBC (Access DB...meh!). Originally I was using threads, because I thought I might be able to process multiple stack elements simultaneously, but then the DBI docs said that wasn't a good idea. If the DBI and drivers are loaded and handles created before the thread is created then it will get a cloned copy of the DBI, the drivers and the handles. However, the internal pointer data within the handles will refer to the DBI and drivers in the original interpreter. Using those handles in the new interpreter thread is not safe, so the DBI detects this and croaks on any method call using handles that don't belong to the current thread (except for DESTROY). I'm about to stop using threads, though I haven't yet because I wasn't sure if I couldn't use them somehow to monitor results from the processing. But then, since I'm only able to go one at a time anyway, I might as well just kill the threads stuff now. I won't pretend that I wasn't a bit curious to play with threads. However, if this is is a bad practice then lesson learned and I'll go another route. dsb This `@ISA my( $cool ) %SIG`	[reply]
Re^3: Handle Signal and Wrap Up by dave_the_m (Parson) on Aug 19, 2005 at 14:44 UTC
What I mean is that if the program is in the middle of processing the 3rd element in the stack and it receives an interrupt signal, I'd like it to finish the 3rd element and ONLY the third element before it exits. `my $stop = 0; $SIG{whatever} = sub {$stop = 1 }; while(@stack and !$stop) { process(shift @stack); ... }` [download] Dave.	[reply] [d/l]
Re^4: Handle Signal and Wrap Up by aukjan (Friar) on Aug 19, 2005 at 18:11 UTC

Handle Signal and Wrap Up

The best material for plates (tableware) is: