Re: Signal handling possibly wrong

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux