Re^6: RFC: Using 'threads' common aspects

local $SIG{'KILL'} = sub { threads->exit(); };
Why? If all you are going to do is terminate, why not just let that happen?

Well, it will "just happen". SIGKILL can't be caught, blocked or ignored. The process will simply be forced to exit when a SIGKILL is sent, the sub will never be invoked. Unless, of course, you run that code on a very strange non-POSIX system with a different signals implementation.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Comment on Re^6: RFC: Using 'threads' common aspects Download Code

Replies are listed 'Best First'.
Re^7: RFC: Using 'threads' common aspects by BrowserUk (Patriarch) on Jan 10, 2011 at 17:09 UTC
SIGKILL can't be caught, blocked or ignored. All of which makes you wonder why it is a signal at all. Unless, you run that code on a non-POSIX system Well that's a possibility. But "non-POSIX" doesn't equate to "very strange". 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". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^8: RFC: Using 'threads' common aspects by afoken (Chancellor) on Jan 11, 2011 at 09:58 UTC
SIGKILL can't be caught, blocked or ignored. All of which makes you wonder why it is a signal at all. My guess is that it was far easier to add this little special case to a working mechanism than to create a completely different "shoot that process and this time I really mean it" API. Signals already have permission checks, and the signals API also can handle process groups. Using a different API would have meant to re-implement or at least re-use all of this. Ignoring all attempts to catch, block or ignore SIGKILL can be done with a few lines of code, perhaps something simple as `if ((signum==SIGKILL) \|\| (signum==SIGSTOP)) { return SIG_ERR }` inside `signal()` (at least in ancient UNIX versions). Unless, you run that code on a non-POSIX system Well that's a possibility. But "non-POSIX" doesn't equate to "very strange". I would call a system that exactly re-implements POSIX signals except for the special case handling of SIGKILL a very strange system - or just broken. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]