guaranteeing interrupt handling

B

badarisj

folks,

the interrupts like INT and QUIT are ignored during the calls to
'system'
builtin. If you have some cleanup code that you DO want executed
how can we guarantee the execution?
especially this problem would be aggravated if your perl-module
depends on bunch of other perl-modules -- you would NOT know
if and when the perl-modules you call are invoking 'system' builtin.

does placing code in DESTROY guarantee the execute with interrupts
like (INT and QUIT)?

thanks,
-badari
 
A

anno4000

folks,

the interrupts like INT and QUIT are ignored during the calls to
'system'
builtin. If you have some cleanup code that you DO want executed
how can we guarantee the execution?

Signal handlers are notoriously unreliable. Any part of the program
can install another one. If you want something executed under all
circumstances don't put it in a signal handler.
especially this problem would be aggravated if your perl-module
depends on bunch of other perl-modules -- you would NOT know
if and when the perl-modules you call are invoking 'system' builtin.

does placing code in DESTROY guarantee the execute with interrupts
like (INT and QUIT)?

DESTROY is called when an object goes out of scope. How would that
apply? You didn't mention objects so far.

You can use an END block, described in perlmod. That will essentially
be executed whenever the program exits, *except* for uncaught
exceptions, so you need to catch signals you expect and die (or exit)
there.

Anno
 
B

badarisj

Signal handlers are notoriously unreliable. Any part of the program
can install another one. If you want something executed under all
circumstances don't put it in a signal handler.


DESTROY is called when an object goes out of scope. How would that
apply? You didn't mention objects so far.

yep. it wouldn't apply to my current situation.
You can use an END block, described in perlmod. That will essentially
be executed whenever the program exits, *except* for uncaught
exceptions, so you need to catch signals you expect and die (or exit)
there.

i would be catching them... BUT what about some other modules i call
choose to install DEFAULT handlers etc.
it would be the same problem as you note above. right?
how can i guarantee that my callers won't muck with my
signal-catching-setup?

i will check the END and see if that works for me...

thanks,
-badari
 
A

anno4000

[...]
You can use an END block, described in perlmod. That will essentially
be executed whenever the program exits, *except* for uncaught
exceptions, so you need to catch signals you expect and die (or exit)
there.

i would be catching them... BUT what about some other modules i call
choose to install DEFAULT handlers etc.
it would be the same problem as you note above. right?
how can i guarantee that my callers won't muck with my
signal-catching-setup?

You can't have an absolute guarantee. After all, you can't catch
SIGDIE and some others.

That said, there is a trick to protect sig handlers against being
overwritten. This one does use DESTROY: Bless the sig handler (a
codref) into a class which has a DESTROY method (and probably not
much else). In the destructor do whatever must be done in that
case. (Untested)

$SIG{ INT} = bless sub { die "Caught a SIGINT" }, 'SafeHandler';

sub SafeHandler::DESTROY {
warn "Someone overwrote a sig handler!";
}


Note that DESTROY is called in the normal course of things during
global destruction. So there'd better be a switch to de-fuse it
so it doesn't complain (not shown, should be activated in END {}).

The mechanism will *not* trigger if the overwriting part of the
program keeps a copy of the original (your) handler, for instance
by localizing $SIG{ ...}. This is considered a feature.

I have used this trick occasionally. It's quite a bit of a hassle and
I don't think it has ever caught anything for me. I'd probably not
use it again, but thought I'd mention it.


Anno
 
X

xhoster

folks,

the interrupts like INT and QUIT are ignored during the calls to
'system'
builtin. If you have some cleanup code that you DO want executed
how can we guarantee the execution?

What clean up code? If you don't get the signal and hence aren't exiting
due to it, what are you cleaning up?
especially this problem would be aggravated if your perl-module
depends on bunch of other perl-modules -- you would NOT know
if and when the perl-modules you call are invoking 'system' builtin.

The vast majority of modules don't invoke the "system" builtin. And if you
wish to tightly control this sort of thing, then you shouldn't use those
modules which do do so.
does placing code in DESTROY guarantee the execute with interrupts
like (INT and QUIT)?

No.

Xho
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top