Re: POSIX signal handling versus traditional signal handling

From: Nils Weller (me_at_privacy.net)
Date: 08/24/05 

Date: 24 Aug 2005 16:27:51 GMT

On 2005-08-24, Ulrich Hobelmann <u.hobelmann@web.de> wrote:
> usenet@sta.samsung.com wrote:
> AFAIK, BSD and POSIX signals (i.e. everything except ooold Unix V7 or
> something) are reliable, so even if you process receives two same

Note that in System V, signal() was never fixed, so you still have to
use sigset() (introduced in SVR3), sigaction() or bsd_signal() instead
to get reliable signals - or link with the BSD compatibility library to
make signal() behave like bsd_signal(). The problem is that POSIX leaves
the choice of reset-or-don't-reset after calling signal() up to the
implementation, so System V derivatives continue to do it the way
they've always done it: Don't reset.

> signals in a short timeframe, the behavior will probably be that after
> the first handler returns, the second signal is delivered. Old behavior

No, the second signal will be lost. sigqueue() can send signals with
the semantics you've described, however. Unfortunately, queued signals
are a realtime extension still not provided by FreeBSD/NetBSD/OpenBSD/
MacOS X (and I seem to recall that older Linux implementations do not
support queueing of non-realtime (SIGRTMIN - SIGRTMAX) signals.) 

-- 
Nils R. Weller, Bremen / Germany
My real email address is ``nils<at>gnulinux<dot>nl''
... but I'm not speaking for the Software Libre Foundation!

Relevant Pages

  • Re: [PATCH] signals: real-time signals delivery order
    ... multiple real-time signals ... static int cnt; ... This modified program works correctly with the original kernel: ... SIGRTMIN + 2, sent with number 5 ...
    (Linux-Kernel)
  • [PATCH] signals: real-time signals delivery order
    ... multiple real-time signals ... Current Linux kernel delivers the highest-numbered signals ... static int cnt; ... SIGRTMIN + 23, sent with number 0 ...
    (Linux-Kernel)
  • Re: different signal numbers for SIGRTMIN... seen on kernel and user.
    ... > We are see a strange behavior while using RT signals. ... In kernel, SIGRTMIN is 32 hardcoded. ...
    (comp.os.linux.development.apps)
  • Re: [SLE] gnupg interfearance
    ... Paul Hewlett wrote: ... > Maybe you have tripped up on some weird interaction between signal, SIGRTMIN ... > and your kernel version... ... environment such that I cannot receive realtime signals. ...
    (SuSE)
  • Re: What if I need more than SIGUSR1 and SIGUSR2?
    ... signal.h shall also declare the macros SIGRTMIN and SIGRTMAX, which evaluate to integer expressions, and specify a range of signal numbers that are reserved for application use and for which the realtime signal behavior specified in this volume of IEEE Std 1003.1-2001 is supported. ... The signal numbers in this range do not overlap any of the signals specified in the following table. ... The range SIGRTMIN through SIGRTMAX inclusive shall include at least signal numbers. ...
    (comp.unix.programmer)