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