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.

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.

I would not put the 'stop' in the while statement, but put it at the end of the loop block, so to do an 'exit if $stop'...

Go Fish!