in reply to Re: Re: Closures, object destruction and memory leaks
in thread Closures, object destruction and memory leaks

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.

  • Comment on Re: Re: Re: Closures, object destruction and memory leaks

Replies are listed 'Best First'.
Re: Re: Re: Re: Closures, object destruction and memory leaks
by mpeppler (Vicar) on Nov 11, 2003 at 15:42 UTC
    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

[reply]
[d/l]
      If your signal handler doesn't do much, then that is probably the right way to do things. And on reflection, having signal handlers not do much is generally the right way to do things.

      My thinking was in case your signal handler did something irrevokable like try to exit, in which case you should allow people to catch it. But if you don't, then don't worry about it. :-)

[reply]
        Ah - I see your logic. No, in a library module I always want to leave as many options as possible to the caller, so calling exit() from the handler isn't something that I'd consider a good idea :-)

        Michael

[reply]

In Section Seekers of Perl Wisdom