I've made some other changes to the code to illustrate what sk and I are talking about.

use constant MAX_ITERATIONS => 100000;
use constant MAX_TIME => 6000;

use warnings;
use strict;

my $start_time = time;
my $iterations = 0;
my $exit_requested = 0;
my $handling_request = 0;

sub sig_handler {
        $exit_requested = 1;
        print "Caught interrupt\n";
        exit(3) if !$handling_request;
}

$SIG{TERM} = \&sig_handler;

#init();
while (!$exit_requested && $iterations <= MAX_ITERATIONS && (time - $s
+tart_time) < MAX_TIME)
{
        $handling_request = 1;
        handle_request();
        $iterations++;
        $handling_request = 0;
        handlyn();
}
exit(0);

#sub init { return 1; }
sub handle_request { 
    handlyn();
    print ("iterations: $iterations\n");
}

sub handlyn { print $handling_request ? "" : "NOT ", "handling\n"; sle
+ep 3; }
[download]

The handlyn() gives me time to send a kill to the process which I'm running from the perl debugger. I then issue a "c 13" in the debugger and wait for the "NOT handling" to be printed, send a kill and then step into the script using "s". You'll see that when $handling_request == 1, the script will exit from line 15. When $handling_request == 0, the script exits from line 29. Which I think is how you want it?

The question is - how does your handle_request work? Is it able to deal with being interrupted only to have execution return to some arbitrary line in the subroutine? What I've done here is to control where the interrupt will occur by giving myself time to send the interrupt at that particular line. But, that isn't how signals generally work in the wild...

Update: corrected link.