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 systemWell 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
In reply to Re^8: RFC: Using 'threads' common aspects
by afoken
in thread RFC: Using 'threads' common aspects
by DeadPoet
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |