[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: POSIX.4 signals + other POSIX.4 stuff to FreeBSD...
From:       Bruce Evans <bde () zeta ! org ! au>
Date:       1996-06-29 6:50:04
[Download RAW message or body]

>/*
> * 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

[prev in list] [next in list] [prev in thread] [next in thread]