src/winsup/cygwin ChangeLog include/cygwin/sig ...

Corinna Vinschen
Fri Oct 26 18:30:00 GMT 2012

On Oct 26 11:21, Eric Blake wrote:
> On 10/26/2012 10:05 AM, Corinna Vinschen wrote:
> >> Oh btw.
> >>
> >> Linux defines all signals beyond SIGRTMIN as RT signals.  Do we follow
> >> the lead or is there some good reason to restrict the number of RT
> >> signals to keep space for later extensions?
> I don't think it is very likely for new signals to appear anywhere (for
> the same reason it's hard for us to swap from 32 to 64 - most
> implementations are now already maxed at 64 and adding a new signal
> would be an ABI change).  So we can probably safely follow suit.  Or we
> can limit to just 8 RT signals, as the minimum guaranteed by POSIX, and
> leave trailing bits for possible extensions.  Oh, and POSIX says
> SIGRTMAX need not be a constant, so if we make it a function call _now_
> (such as something based on sysconf(_SC_RTSIG_MAX)), then we can always
> have that return a smaller value later - applications that use RT
> signals already have to be prepared for the set of RT signals to be
> dynamically sized according to POSIX.

If there's no reason to keep space, I would opt for this implementation:

#ifdef __x86_64__
#define NSIG    65      /* signal 0 implied */
#define NSIG    33      /* signal 0 implied */

/* Real-Time signals per SUSv3.  RT_SIGMAX in limits.h has to agree. */
#define SIGRTMIN 32
#define SIGRTMAX (NSIG - 1)

It's not dynamic, but it doesn't seem to make a lot of sense to make it
dynamic.  Even in the 32 bit case, if we change the number of available
RT signals it can also occur together with the ABI change, so an old
application would still have the old number of RT signals, despite any
effort to make the number dynamic.  Me thinks.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list