Date: Fri, 28 Jun 1996 19:32:04 +0300 (EET DST) From: Jukka Ukkonen <jau@jau.csc.fi> To: terry@lambert.org (Terry Lambert) Cc: bde@zeta.org.au, hackers@freebsd.com Subject: Re: POSIX.4 signals + other POSIX.4 stuff to FreeBSD... Message-ID: <199606281632.TAA22857@jau.csc.fi> In-Reply-To: <199606271833.LAA05478@phaeton.artisoft.com> from "Terry Lambert" at Jun 27, 96 11:33:41 am
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Terry Lambert:
>
> Use the extended structure size only in the extension interfaces, and
> assume defaults for the non-extension interfaces (you will have to
> do this as part of the ABI mapping in any case). I did something
> similar to this for the fcntl() calls for NFS server locking, which
> requires system and process ID's for the proxy.
Eh? As I already said, the new and the old call interface would
have to co-exist for some time, so that the old programs using
the old interface would not break. (This might prove out to be
a slippery road to take, but maybe it would be possible. I don't
know about the shared libraries though.)
There are only three completely new system calls or functions
defined by POSIX.4 for the signals.
extern int sigqueue __P((pid_t, int, const union sigval));
extern int sigwaitinfo __P((const sigset_t *, siginfo_t *));
extern int sigtimedwait __P((const sigset_t *, siginfo_t *,
const struct timespec *));
The new or modified data structures in POSIX.4 are as follows...
union sigval {
int sival_int;
void *sival_ptr; /* Remember to cast this correctly! */
};
struct sigevent {
int sigev_notify; /* SIGEV_SIGNAL or SIGEV_NONE */
int sigev_signo; /* signal to raise for this event */
union sigval sigev_value; /* queue the signal with this value */
};
struct siginfo {
int si_signo; /* redundant signal number */
int si_code; /* facility that raised this signal */
union sigval si_value; /* value that was queued with signal */
};
typedef struct siginfo siginfo_t;
#define SIGEV_NONE 0 /* don't notify */
#define SIGEV_SIGNAL 1 /* use signals for notification */
#define SIGEV_THREAD 2 /* from POSIX.4a - the threads */
#define SI_USER 0x01 /* sent without data by application code */
#define SI_QUEUE 0x02 /* sent with data by application code */
#define SI_TIMER 0x04 /* raised by an expired timer */
#define SI_ASYNCIO 0x08 /* raised by completed async. I/O */
#define SI_MESGQ 0x10 /* data waiting in a message queue */
/*
* 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 *));
};
sigset_t sa_mask; /* signal mask to apply */
int sa_flags; /* see signal options below */
};
POSIX.4 also adds the flag SA_SIGINFO which enables the real-time
queueing signal behaviour. When SA_SIGINFO is set the handler has
to be able to accept the new sa_sigaction type parameter list.
Otherwise the old sa_handler type parameter list should be used.
All the rest of the signals system is just as before and the
old call interface is expected to be able to operate also with
the new RT-signals. These are just kind of added USRxx signals.
The extended functionality of the signals system call interface
is very much a distinct idea. The increased number of user
definable signals is there just to make useful the new more
complex functionality of the call interface.
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?
#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.
Cheers,
// jau
------
/ Jukka A. Ukkonen, FUNET / Centre for Scientific Computing
/__ M.Sc. (sw-eng & cs) Tel: (Home&Fax) +358-0-6215280
/ Internet: ukkonen@csc.fi (Work) +358-0-4573208
v Internet: jau@funet.fi (Mobile) +358-400-606671
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606281632.TAA22857>