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

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

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