Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > guaranteeing interrupt handling

Reply
Thread Tools

guaranteeing interrupt handling

 
 
badarisj@gmail.com
Guest
Posts: n/a
 
      11-10-2006
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

 
Reply With Quote
 
 
 
 
anno4000@radom.zrz.tu-berlin.de
Guest
Posts: n/a
 
      11-10-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) <(E-Mail Removed)> wrote in comp.lang.perl.misc:
> 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
 
Reply With Quote
 
 
 
 
badarisj@gmail.com
Guest
Posts: n/a
 
      11-10-2006

http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de wrote:
> (E-Mail Removed) <(E-Mail Removed)> wrote in comp.lang.perl.misc:
> > 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.


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

>
> Anno


 
Reply With Quote
 
anno4000@radom.zrz.tu-berlin.de
Guest
Posts: n/a
 
      11-10-2006
(E-Mail Removed) <(E-Mail Removed)> wrote in comp.lang.perl.misc:
>
> (E-Mail Removed)-berlin.de wrote:
> > (E-Mail Removed) <(E-Mail Removed)> wrote in comp.lang.perl.misc:
> > > 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?


[...]

> > 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:ESTROY {
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
 
Reply With Quote
 
xhoster@gmail.com
Guest
Posts: n/a
 
      11-10-2006
"(E-Mail Removed)" <(E-Mail Removed)> wrote:
> 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

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Policy Routing: Guaranteeing Bandwidth Question Mysticmoose06 Cisco 6 03-29-2007 09:30 PM
interrupt handling in Java CDMahajan Java 1 03-26-2006 11:25 PM
Handling interrupt Marco C Programming 2 05-13-2005 12:52 PM
Guaranteeing that a function does *not* exist strnbrg@trhj.homeunix.net C++ 4 04-22-2005 03:35 AM
where can i find the core code of intel 8259A interrupt controller? Tony VHDL 0 11-13-2003 09:21 AM



Advertisments