sub execute {
    my $self = shift;

    my $req = BigHairyDatabaseInteraction->new(...);
    {
        local $SIG{INT} = sub {$req->{_signal} = 2;
                               $req->handleInterrupt; };
        local $SIG{TERM} = sub {$req->{_signal} = 15;
                                $req->handleInterrupt; };
        $req->executeRequest();
    }
    # If a TERM/INT signal has been delivered during the request
    # then pass it on to the program itself:
    if($req->{_signal}) {
        kill $req->{_signal}, $$;
    }
    ... rest of $sth->execute()
[download]

So far this appears to work really well...

Michael

One tip that may make sense.

Before you do the local, capture the existing handlers in lexical variables and pass them in to $req's handleInterrupt method.

That way if a particular request type wants to, it can rethrow an exception properly up the chain, rather than just ignoring the poor programmer who is trying to put a signal handler around your code because they really don't want to exit on that signal.

Doing this makes the signal handler system act a little bit more like a proper exception handling system. Not that much more like, mind you, but somewhat more like it.

Hmm - that was why I have the

if($req->{_signal}) {
    kill $req->{_signal}, $$;
}
[download]

bit. That re-delivers the signal to the program, rather than chaining the handlers, but won't that achieve the same end-result?

In any case the $req->handleInterrupt() call really only sets a flag in the $req object, so chaining the signal handlers here would potentially prevent the request from being properly cancelled on the server, which I think could be a problem.

Michael

I _think_ the memory leak you mean only comes up with recursive closures:

my $foo;
$foo=sub { $foo->(@_[1..$#_]) if @_ };
$foo->();
[download]

But like you I dont remember the details...

Recursive closures leak memory. That is documented and the fix is to use WeakRef.

What I am talking about is an actual bug, and I darned well know that it was there in 5.005_03 because I encountered it and had to fix a bunch of code that was leaking memory too fast.