All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
To: Robert Wilkens <robw@optonline.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Signal handling possibly wrong
Date: Tue, 09 Aug 2005 20:44:27 +0200	[thread overview]
Message-ID: <42F8F98B.3080908@fujitsu-siemens.com> (raw)
In-Reply-To: <1123612789.3167.9.camel@localhost.localdomain>

Robert Wilkens wrote:
> Bodo,
> 
> SA_MASK is a flag... Which you use to tell it what to do with the data
> you've given it and/or it gets.  You gave it sa_mask (lower-case).
> SA_NOMASK means don't use the mask -- the pseudonym (new-word) for
> SA_NOMASK is SA_NODEFER (renamed, perhaps, because it may defer some or
> all signals rather than throwing them away, you probably can receive the
> waiting signals by clearing the SA_NODEFER flag on a subsequent call).
> 
> If you want to take this off-list, I'm OK with that..
> 
> Please describe what you would expect SA_NODEFER to do in your own
> language if you don't understand what I seem to understand.
> 
> -Rob
> On Tue, 2005-08-09 at 20:32 +0200, Bodo Stroesser wrote:
> 

Sorry, unfortunately you are not right. See this (from man page for sigaction):

struct sigaction {
                   void (*sa_handler)(int);
                   void (*sa_sigaction)(int, siginfo_t *, void *);
                   sigset_t sa_mask;
                   int sa_flags;
                   void (*sa_restorer)(void);
               }

Please read the text about element sa_mask of struct sigaction to
understand what I'm talking about.

Regards
	Bodo


>>Robert Wilkens wrote:
>>
>>>>Kernel code blocks both "handled signal" _and_ sa_mask only if SA_NODEFER
>>>>isn't set.
>>>>
>>>>Which is the right behavior?
>>>
>>>
>>>Perhaps both?
>>>
>>>I'm novice here, but if i'm reading the man page correctly, it says:
>>>
>>>SA_NODEFER
>>>   Do not prevent the signal from being received from within
>>>   its  own  signal handler. 
>>>	(they also imply that SA_NOMASK is the old name for this,
>>>	which might make it clear what it's use is).
>>>
>>>In which case blocking (masking) when it's not set is exactly what it's
>>>supposed to do.
>>>
>>>-Rob
>>
>>Yes. That's true.
>>
>>But what about sa_mask? Description of SA_NODEFER and sa_mask both do not
>>say, that usage of sa_mask depends on SA_NODEFER.
>>But kernel only uses sa_mask, if SA_NODEFER isn't set.
>>
>>So, I think man page and kernel are not consistent.
>>
>>	Bodo
>>-
>>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/

  reply	other threads:[~2005-08-09 18:44 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-09 17:44 Signal handling possibly wrong Bodo Stroesser
2005-08-09 18:26 ` Robert Wilkens
2005-08-09 18:32   ` Bodo Stroesser
2005-08-09 18:39     ` Robert Wilkens
2005-08-09 18:44       ` Bodo Stroesser [this message]
2005-08-09 19:04         ` Robert Wilkens
2005-08-09 19:33           ` Steven Rostedt
2005-08-09 19:41             ` Bodo Stroesser
2005-08-09 20:03               ` Steven Rostedt
2005-08-09 20:19                 ` Steven Rostedt
2005-08-09 20:49                   ` Chris Wright
2005-08-09 21:00                     ` [PATCH] Fix i386 signal handling of NODEFER, should not affect sa_mask (was: Re: Signal handling possibly wrong) Steven Rostedt
2005-08-09 21:06                       ` Chris Wright
2005-08-09 21:07                       ` [PATCH] Fix PPC signal handling of NODEFER, should not affect sa_mask Steven Rostedt
2005-08-09 21:27                         ` Linus Torvalds
2005-08-10  3:10                           ` Steven Rostedt
2005-08-10  3:33                             ` Steven Rostedt
2005-08-12 18:37                             ` Jan Engelhardt
2005-08-12 18:45                               ` Chris Wright
2005-08-12 18:59                                 ` Steven Rostedt
2005-08-12 19:27                                   ` Steven Rostedt
2005-08-12 19:31                                   ` Jesper Juhl
2005-08-12 21:08                                     ` Steven Rostedt
2005-08-14 11:24                                       ` Jesper Juhl
2005-08-12 21:53                                     ` Steven Rostedt
2005-08-14 22:04                                       ` Kyle Moffett
2005-08-13 18:47                                   ` Marc Ballarin
2005-08-10  9:44                           ` Bodo Stroesser
2005-08-09 21:04                     ` Signal handling possibly wrong Chris Wright
2005-08-10  9:11                     ` Bodo Stroesser
2005-08-10 16:20                       ` Chris Wright
2005-08-09 19:33           ` Jeremy Maitin-Shepard
2005-08-09 18:50 ` smbus driver for ati xpress 200m yhlu
2005-08-09 22:57   ` Andi Kleen
2005-08-10  2:51     ` yhlu
2005-08-10  7:27       ` Andi Kleen
     [not found] <11855.1123690475@www37.gmx.net>
2005-08-10 16:22 ` Signal handling possibly wrong Michael Kerrisk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42F8F98B.3080908@fujitsu-siemens.com \
    --to=bstroesser@fujitsu-siemens.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robw@optonline.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.