Re^4: trouble with custom signal handlers

(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.

Comment on Re^4: trouble with custom signal handlers

Replies are listed 'Best First'.
Re^5: trouble with custom signal handlers by Marshall (Canon) on Apr 17, 2016 at 15:55 UTC
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]
Re^6: trouble with custom signal handlers by BrowserUk (Patriarch) on Apr 17, 2016 at 17:40 UTC
Just re-installing the signal handlers after the call to Safe will work with the exception of what happens while Safe is running. I think that is the point of Safe. To make sure that nothing can do anything that Safe doesn't permit. It's not trying to be polite; it is trying to impose absolute order; in order that it can provide certain guarantees. 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]
Re^7: trouble with custom signal handlers by Marshall (Canon) on Apr 17, 2016 at 19:19 UTC
I think that we are "on the same page". If the interrupt is already masked out, then Safe doesn't have to do anything, but it is likely that this critter does things that it doesn't need to do. "polite" would mean not doing anything with something that was already meant to have nothing happen. It could very well be that there is no "safe" way to call Safe if the user programs wants to handle a signal.	[reply]