Messages in this thread |  | | | Date | Tue, 09 Aug 2005 20:44:27 +0200 | | From | Bodo Stroesser <> | | Subject | Re: Signal handling possibly wrong |
| |
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/ - 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/
|  |