On 02/22/2012 04:50 PM, Roland McGrath wrote: > On Wed, Feb 22, 2012 at 4:29 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> Can we really introduce force-kill semantics for a POSIX-defined signal? >> Other user space programs might use it for other purposes. > > The semantics are based on how the signal was generated, not what signal > number it was. The only thing that depends on the signal number is > SYNCHRONOUS_MASK, which just determines in which order pending signals are > dequeued (POSIX says it may be any order). We only have that so your state > doesn't get unhelpfully warped to another signal handler entry point > (including fiddling the stack) before you dump core. > > No use of SIGSYS is specified by POSIX at all, of course, since "system > call" is an implementation concept below the level POSIX specifies. I meant whether or not a signal can be blocked/caught and the fact that the signal exists at all. Now I guess we could have "blockable" and "unblockable" SIGSYS, but that would seem to have its own set of issues... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
