Re: Signal handling possibly wrong

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

 



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