in reply to Signal handling in embedded Perl ?

Without knowing the details (so this probably isn't too helpful) I think the normal way of achieving this sort of goal is to chain things so that when you install a signal handler, you save the previous signal handler. When you've finished any handling you want to do, you invoke the saved, chained handler (passing in the same args you received).

This scheme works even with one set of signal handlers which don't play nicely, if you can arrange for those to be installed first, all the chain-aware ones can be installed afterwards and the unfriendly ones can be called at the end of the chain.

Sorry this is so vague, but routines for managing these things generally return the previous signal handler in order for you to do this. The old-style 'signal()' returns the previous handler, the POSIX sigaction takes an 'oldact' struct pointer to copy in the previous handling details (if requested)).

Or are you saying that your platform lacks signal or sigaction? If so, can you mock up an equivalent using your platform's primitives?

Replies are listed 'Best First'.
Re^2: Signal handling in embedded Perl ?
by jdrago_999 (Hermit) on Nov 21, 2006 at 15:16 UTC
    Just for example's sake, something like this?
    sub install_handler { my ($sig, $subref) = @_; my $original = $SIG{$sig} || sub{}; $SIG{$sig} = sub { $subref->(); $original->(); } }
      That would be the equivalent in perl, yes.

      But when embedding perl inside another program/platform, you'd be doing the same thing at the C level, and calling the POSIX sigaction() function (or its equivalent).

      (At least I think you would - I'd be very suprised if the existing value of $SIG{FOO} you stored in $original was a callable C function. But then, I've been surprised before).

      And being in C not perl, you wouldn't have the convenience of having a nice closure to capture your state, so you'd need to have a data structure (perhaps a global array indexed by signal number).