[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
signature.asc
Description: OpenPGP digital signature