Re: Signal handling possibly wrong

[Bodo Stroesser <bstroesser@fujitsu-siemens.com>]

Steven Rostedt wrote:
> On Tue, 2005-08-09 at 15:04 -0400, Robert Wilkens wrote:
>
> > [resent - previous message not properly addressed]
> >
> > It says "signal is blocked, UNLESS SA_NODEFER is used.."
> >
> > Which means if NODEFER is used, it's not masked (SA_NOMASK)..
>
>
> I believe I understand what Bodo is saying.  The man pages seem to imply
> that the NODEFER only affects the signal being sent. Where as, in the
> kernel, the NODEFER flag affects all signals in the sa_mask.
>
> Let's look at the man pages again:
>
>        sa_mask gives a mask of signals which should be blocked  during  execu-
>        tion  of  the  signal handler.  In addition, the signal which triggered
>        the handler will be blocked, unless the SA_NODEFER flag is used.
>
> The "In addition" is what makes this look like the kernel is wrong. So
> the man pages says that the sa_mask is the mask of signals that should
> be blocked during exection of the signal handle (regardless) of the
> SA_NODEFER.  It doesn't imply that the sa_mask would only work if the
> SA_NODEFER was not set.  The SA_NODEFER seems to imply here that, if
> set, the signal that is running could be called again.
>
> It also seems to imply the other way around. That is, that the signal
> that is running would be blocked regardless of the sa_mask, and only
> would not be blocked if the SA_NODEFER is set.
>
> To me, the man pages make more sense, and I think the kernel is wrong.

Yes, that's what I think, too. If someone doesn't want additional signals
to be masked, he can set sa_mask to be empty.
OTOH, I have no idea, what POSIX specifies. Maybe kernel is right and man
page is wrong?

	Bodo
> > I don't understand how i'm wrong (maybe I have mental problems that are
> > worse than I thought).  If you want to explain off-list or on-list
> > (depending on whether others are getting annoyed at me) you can.  Or
> > just ignore me and i'll go away and someone else who wants to look at it
> > can.
>
>
> Don't take this off list, since I'm sure there are others here that can
> add valid input.
>
> -- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/