Obsolete SIGRTMAX-n signal names

[Harald Hoyer]

As reported in http://savannah.gnu.org/patch/?8025 , I would like to see the
SIGRTMAX-n signal names disappear.

Signals should never ever be addressed with SIGRTMAX-n. Signals should always be
addressed with SIGRTMIN+n.

http://man7.org/linux/man-pages/man7/signal.7.html
[...]
programs should never refer to real-time signals using hard-coded numbers, but
instead should always refer to real-time signals using the notation SIGRTMIN+n
[...]

This patch makes the SIGRTMIN+n notation the default, but understands the old
SIGRTMAX-n notation as well.

http://savannah.gnu.org/patch/download.php?file_id=27910

[Chet Ramey]

On 4/23/13 2:05 AM, Harald Hoyer wrote:
> As reported in http://savannah.gnu.org/patch/?8025 , I would like to see the
> SIGRTMAX-n signal names disappear.
>
> Signals should never ever be addressed with SIGRTMAX-n. Signals should always be
> addressed with SIGRTMIN+n.

I'll take a look at this, but that's a pretty strong statement to make from
something that appears in one Linux man page. I can't find any shell in my
quick testing that behaves as you propose. Is there any other reason to do
this?

Chet


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU ch...@case.edu http://cnswww.cns.cwru.edu/~chet/

[Harald Hoyer]

On 04/24/2013 05:26 PM, Chet Ramey wrote:
> On 4/23/13 2:05 AM, Harald Hoyer wrote:
>> As reported in http://savannah.gnu.org/patch/?8025 , I would like to see the
>> SIGRTMAX-n signal names disappear.
>>
>> Signals should never ever be addressed with SIGRTMAX-n. Signals should always be
>> addressed with SIGRTMIN+n.
>
> I'll take a look at this, but that's a pretty strong statement to make from
> something that appears in one Linux man page. I can't find any shell in my
> quick testing that behaves as you propose. Is there any other reason to do
> this?
>
> Chet
>
>

Well, the value SIGRTMAX-n might change, if SIGRTMAX grows. SIGRTMIN+n should be
constant. So, users should not be encouraged to use SIGRTMAX-n.

[Harald Hoyer]

On 04/24/2013 05:26 PM, Chet Ramey wrote:
> On 4/23/13 2:05 AM, Harald Hoyer wrote:
>> As reported in http://savannah.gnu.org/patch/?8025 , I would like to see the
>> SIGRTMAX-n signal names disappear.
>>
>> Signals should never ever be addressed with SIGRTMAX-n. Signals should always be
>> addressed with SIGRTMIN+n.
>
> I'll take a look at this, but that's a pretty strong statement to make from
> something that appears in one Linux man page. I can't find any shell in my
> quick testing that behaves as you propose. Is there any other reason to do
> this?
>
> Chet
>
>

Any progress, comments?

[John Reiser]

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)].

--

[Eric Blake]

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