guaranteeing interrupt handling

Discussion in 'Perl Misc' started by badarisj@gmail.com, Nov 10, 2006.

  1. Guest

    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
    , Nov 10, 2006
    #1
    1. Advertising

  2. -berlin.de Guest

    <> 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
    -berlin.de, Nov 10, 2006
    #2
    1. Advertising

  3. Guest

    -berlin.de wrote:
    > <> 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
    , Nov 10, 2006
    #3
  4. -berlin.de Guest

    <> wrote in comp.lang.perl.misc:
    >
    > -berlin.de wrote:
    > > <> 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::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
    -berlin.de, Nov 10, 2006
    #4
  5. Guest

    "" <> 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
    , Nov 10, 2006
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tony
    Replies:
    0
    Views:
    1,032
  2. prabhu
    Replies:
    1
    Views:
    514
    Ralf Hildebrandt
    Feb 25, 2004
  3. CDMahajan

    interrupt handling in Java

    CDMahajan, Mar 26, 2006, in forum: Java
    Replies:
    1
    Views:
    3,963
    Roedy Green
    Mar 27, 2006
  4. Replies:
    4
    Views:
    323
    David White
    Apr 22, 2005
  5. Marco

    Handling interrupt

    Marco, May 11, 2005, in forum: C Programming
    Replies:
    2
    Views:
    384
    -berlin.de
    May 13, 2005
Loading...

Share This Page