[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Obsolete SIGRTMAX-n signal names

From: Eric Blake
Subject: Re: Obsolete SIGRTMAX-n signal names
Date: Wed, 29 May 2013 09:14:14 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

On 05/29/2013 09:04 AM, John Reiser wrote:

> Comment: In practice SIGRTMIN is a very stable value.  For each architecture
> SIGRTMIN is chosen at the time of the original port, and after that SIGRTMIN
> "never" will change, although in theory it could.  The value of SIGRTMAX
> is less stable because it changes whenever _NSIG changes.  _NSIG has changed
> from 32 to 64, and in some cases has reverted to 32 in order to save 4 bytes
> [or 4*sizeof(void *)] in various places, and to make code smaller and simpler
> [because (32/8)==sizeof(unsigned int)].

_NSIG == 32 is only possible on platforms that are not aiming for POSIX
compliance; POSIX requires enough signals, including a minimum of 8
realtime signals, that you pretty much need _NSIG == 64 to comply with
POSIX.  That said, cygwin is a platform that has not (yet) converted to
_NSIG == 64, and currently cheats by providing SIGRTMIN == SIGRTMAX for
only 1 realtime signal.

I agree that SIGRTMIN is unlikely to change for a given platform, except
in the rare case of an API change from 32 to 64 (requiring a recompile
of pretty much everything on that platform to take advantage of the new
API, while still providing ABI compatibility for older applications to
continue to run even without recompilation).

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]