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

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.

Comment on Re^7: RFC: Using 'threads' common aspects

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]