in reply to Re: trouble with custom signal handlers
in thread trouble with custom signal handlers

Safe almost certainly uses signal handlers; and on the evidence of this code, it apparently doesn't restore any old ones.

The solution might be to wrap reval() with code that saves and restores any existing signal handlers either side of calling that method.

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 knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^2: trouble with custom signal handlers

Replies are listed 'Best First'.
Re^3: trouble with custom signal handlers
by casaschi (Novice) on Apr 17, 2016 at 14:42 UTC
    Thanks for the confirmation. I'll probably do what you suggest although it should really be fixed in the Safe module (why does Safe need to reset ALL signal handlers?). Otherwise I can see cases where a signal at the wrong time could have unpredictable effects.
[reply]
      (why does Safe need to reset ALL signal handlers?)

      Because it is the only way to be Safe. Otherwise, the arrival of a signal could cause the signal handler code to be called; and it would be completely outside of Safe's control, and could do anything!

      But yes; it should restore what was there when it was called.

      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 knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        If the signal handlers are just re-installed after calling Safe, then I think there is the possibility of missing a signal (one that occurs while Safe is running).

        The Safe author(s) had 3 options: 1) Temporarily block usr1,2 and do nothing and wait for caller to figure it out later, 2)throw these signals away, 3)do something of its own which probably ain't that polite.

        One possible? solution is to block Usr1 and Usr2 before calling Safe, but that requires C code and requires Safe to be "well behaved". I don't know of anyway in Perl to modify the signal mask. In this case to not miss a signal, caller then re-installs the signal handlers and then unblocks the signals. Then any pending signal would be delivered. It is possible for the OS to have a "pending, but not delivered" signal.

        A big issues here is "how well behaved" Safe is? Sounds like its not very "polite". If it installs its own handlers but doesn't unblock the USR signals and essentially "take over the world", then that can be worked around with effort.

        Just re-installing the signal handlers after the call to Safe will work with the exception of what happens while Safe is running. It appears to me that not everything is "safe" with Safe. A signal might not just be delayed, but missed which is different.

        I did look at the Safe doc's and it appears to me that this thing would flunk the Kindergarten grade of "plays well with others".

[reply]

In Section Seekers of Perl Wisdom