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

[Eric Blake]

CVSROOT: /cvs/src
Module name: src
winsup/cygwin : ChangeLog
winsup/cygwin/include/cygwin: signal.h
* include/cygwin/signal.h (sigset_t): Define here.
+typedef __uint32_t sigset_t;

Are there plans to widen this to 64 bits for 64-bit cygwin, so that we
can finally implement real-time signals as required by POSIX?

[Corinna Vinschen]

Post by Eric Blake

CVSROOT: /cvs/src
Module name: src
winsup/cygwin : ChangeLog
winsup/cygwin/include/cygwin: signal.h
* include/cygwin/signal.h (sigset_t): Define here.
+typedef __uint32_t sigset_t;

Are there plans to widen this to 64 bits for 64-bit cygwin, so that we
can finally implement real-time signals as required by POSIX?

Look at the end of

http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/signal.h.diff?cvsroot=src&only_with_tag=cygwin-64bit-branch&r1=1.19.4.1&r2=1.19.4.2

ABI changes galore, just as with time_t. Somebody has to... well, you
know.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Eric Blake

CVSROOT: /cvs/src
Module name: src
winsup/cygwin : ChangeLog
winsup/cygwin/include/cygwin: signal.h
* include/cygwin/signal.h (sigset_t): Define here.
+typedef __uint32_t sigset_t;

Are there plans to widen this to 64 bits for 64-bit cygwin, so that we
can finally implement real-time signals as required by POSIX?

Look at the end of
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/signal.h.diff?cvsroot=src&only_with_tag=cygwin-64bit-branch&r1=1.19.4.1&r2=1.19.4.2
ABI changes galore, just as with time_t. Somebody has to... well, you
know.

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?


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by Corinna Vinschen

Post by Eric Blake

CVSROOT: /cvs/src
Module name: src
winsup/cygwin : ChangeLog
winsup/cygwin/include/cygwin: signal.h
* include/cygwin/signal.h (sigset_t): Define here.
+typedef __uint32_t sigset_t;

Are there plans to widen this to 64 bits for 64-bit cygwin, so that we
can finally implement real-time signals as required by POSIX?

Look at the end of
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/signal.h.diff?cvsroot=src&only_with_tag=cygwin-64bit-branch&r1=1.19.4.1&r2=1.19.4.2
ABI changes galore, just as with time_t. Somebody has to... well, you
know.

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 see one signal in Linux which we don't have yet, SIGSTKFLT. Is it
worth to keep space for that?


Corinna

[Eric Blake]

Post by Corinna Vinschen

Post by Corinna Vinschen
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.

Post by Corinna Vinschen
I see one signal in Linux which we don't have yet, SIGSTKFLT. Is it
worth to keep space for that?

It's non-standard, and I have no idea under what conditions Linux
generates it for us to even emulate it.

[Corinna Vinschen]

Post by Eric Blake

Post by Corinna Vinschen
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 */
#else
#define NSIG 33 /* signal 0 implied */
#endif

/* 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

[Eric Blake]

Post by Corinna Vinschen
#ifdef __x86_64__
#define NSIG 65 /* signal 0 implied */
#else
#define NSIG 33 /* signal 0 implied */
#endif
/* 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.

Seems reasonable to me - if there is ever a new signal added, we'd also
want to add it to 32-bit cygwin, at which point we will have to tackle
the ABI problem, and can therefore tackle the ABI problem in both builds
at once.

[Corinna Vinschen]

Post by Eric Blake

Post by Corinna Vinschen
#ifdef __x86_64__
#define NSIG 65 /* signal 0 implied */
#else
#define NSIG 33 /* signal 0 implied */
#endif
/* 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.

Seems reasonable to me - if there is ever a new signal added, we'd also

I don't quite understand. The joke here is that the above would NOT allow
to add any further signal. Ever. Except for more RT signals in the 32
bit case. What am I missing?


Corinna

[Eric Blake]

Post by Corinna Vinschen

Post by Eric Blake

Post by Corinna Vinschen
#ifdef __x86_64__
#define NSIG 65 /* signal 0 implied */
#else
#define NSIG 33 /* signal 0 implied */
#endif
/* 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.

Seems reasonable to me - if there is ever a new signal added, we'd also

I don't quite understand. The joke here is that the above would NOT allow
to add any further signal. Ever. Except for more RT signals in the 32
bit case. What am I missing?

If we ever add a new signal, it would be an ABI change - code compiled
against old cygwin.dll would call into the old ABI, where there are 32
or 64 total signsl with 1 or 33 RT signals and no access to the new
signal; new code would call into the new ABI where there are 64 total
signals (even on 32-bit cygwin) and the new signal has been carved out
appropriately. That is, the cost of adding a new signal for 32-bit
cygwin is an ABI change, but if we do the ABI change, we can also do it
for 64-bit cygwin at the same time.

But I think this is theoretical - we are unlikely to add a new signal,
so go with the above definition without worrying about it.