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