belg4mit has asked for the wisdom of the Perl Monks concerning the following question:

Hello all, is there some way for code within a signal handler to affect the greater program? I found Setting up signal handlers for an object with access to $self, which has allowed me access to my data within the signal handler, but neither changes to the object nor the %ENVironment seem to persist. I suspect it's not possible, but am wondering if there's something I am overlooking.

For those curious, the goal is to install a handler that will handle broken pipes elegantly and fail over to a fallback. $SIG{PIPE} = 'IGNORE' is insufficient, and wrapping the calls that work with the pipe in eval{} fails the elegance test… Cheers!

UPDATE: In the end it turned out to be possible to get information out of the signal handler, but block eval was still required. However I hit upon a relatively elegant means of using it: Rather than wrapping multiple statements within eval. I decided to put everything in an eval block, and use it as a replacement for do in my control structure e.g;

eval{ ... } while ($condition);

In Bob We Trust, All Others Bring Data.

Replies are listed 'Best First'.
Re: Spooky actions from a signal handler possible?
by BrowserUk (Patriarch) on Feb 24, 2015 at 19:51 UTC
    but neither changes to the object nor the %ENVironment seem to persist.

    Hm. The second part of that is incorrect:

    #! perl -slw use strict; $SIG{ INT } = sub { print 'SIGINT called'; $ENV{ fred } = 12345; return; }; $ENV{ fred } = 0; while( sleep 1 ) { print $ENV{ fred }; } __END__ C:\test>junk10 0 0 0 0 0 0 SIGINT called 12345 12345 12345 12345 12345 12345 12345 Terminating on signal SIGBREAK(21)

    Which probably means that I've misunderstood your intent. Perhaps you could post some code to demonstrate the problem?

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
      Apparently PIPE and INT are different. That works, but only if the code that triggers the PIPE is in a block eval. My code is a little hairy at the moment though, so coming up with a suitable example is proving tricky.

      In Bob We Trust, All Others Bring Data.

Re: Spooky actions from a signal handler possible?
by RonW (Parson) on Feb 24, 2015 at 20:19 UTC

    Interrupt handlers in Perl are able to modify package variables, so your handler could change a flag. If a designated package variable contains an object reference, then your handler could change the value of a field in that object.

    For your situation, may need to use the :perlio layer with the file handles associated with the pipes.

    See Perl IPC Signals, including the discussion of Deferred Signals and Interrupting IO

      Oh believe me, I read and reread perlipc, perldoc -f open, etc. etc. many times to try figure out how to go about this :-P I am using 5.8.0+ with the default :perlio on the handle. Thanks though.

      In Bob We Trust, All Others Bring Data.