Date: Sat, 29 Jun 1996 16:50:04 +1000 From: Bruce Evans <bde@zeta.org.au> To: jau@jau.csc.fi, terry@lambert.org Cc: bde@zeta.org.au, hackers@freebsd.com Subject: Re: POSIX.4 signals + other POSIX.4 stuff to FreeBSD... Message-ID: <199606290650.QAA27894@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>/*
> * Signal vector "template" used in sigaction call.
> */
>struct sigaction {
> union {
> /*
> * These two could be separate fields quite as well.
> *
> * Either a simple POSIX.1 signal handler
> * with additional BSD style parameters ...
> */
> void (*sa_handler) _P((int, ...));
> /*
> * ... or a more complex POSIX.4 signal handler
> */
> void (*sa_sigaction) _P((int, siginfo_t *, void *));
> };
How can POSIX.4 specify this? It is incompatible with the POSIX.1
struct sigaction (as is the varargs sa_handler).
> Though Bruce Evans seems not to share my opinion, I suppose
> using sigismember() etc. macros/functions within the kernel
> would not be very much a resource hog, or what do you think
> of the next macro?
I only said that the would be unnecessarily inefficient with [if sigset_t
is <= 32 bits].
>#define sigismember(set, sig) (set[((unsigned) (sig)) >> 5] \
> & (1 << ((sig) & 0x1F)))
> This does not really require too many extra machine instructions
> when used instead of the simple bitwise and/or logic. This already
> accounts for the ability to handle an extended signal set.
The user sigismember() is more or less required to check the bounds, so
it needs to be larger and uglier. The kernel should probably check `sig'
in advance and then use special kernel versions of the signal manipulation
functions.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606290650.QAA27894>