in reply to Re^7: RFC: Using 'threads' common aspects
in thread 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.

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". ;-)