Cygwin 3.6: Supporting 128 POSIX realtime (SIGRTMAX-SIGRTMIN >= 128) signals?
Corinna Vinschen
corinna-cygwin@cygwin.com
Tue Mar 4 11:38:52 GMT 2025
On Mar 4 12:20, Lionel Cons via Cygwin wrote:
> On Tue, 4 Mar 2025 at 11:08, Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> >
> > On Mar 3 23:07, Lionel Cons via Cygwin wrote:
> > > On Mon, 3 Mar 2025 at 12:43, Corinna Vinschen via Cygwin
> > > <cygwin@cygwin.com> wrote:
> > > >
> > > > On Feb 28 15:36, Lionel Cons via Cygwin wrote:
> > > > > We've hit a scalability issue in Cygwin today, the application in
> > > > > question ran out of POSIX realtime signals (i.e. SIGRTMIN-SIGRTMAX).
> > > > >
> > > > > Could Cygwin support 128 POSIX realtime signals?
> > > >
> > > > Not possible. sigset_t is an unsigned long, thus we can only support
> > > > up to 64 signals.
> > > >
> > > > A change to a bigger sigset_t is an ABI breakage and requires two
> > > > different entry points for all functions touching the sigset_t type, one
> > > > for the new definition of sigset_t, one for backward compatibility with
> > > > existing applications. This *could* be part of 3.7, but I don't make
> > > > any promises.
> > >
> > > gcc has int128_t - would that help you?
> >
> > Not at all. It doesn't change the underlying problem of the ABI breakage.
>
> That is... bad.
> For the new ABI, maybe store a pointer to the byte array which holds
> the signal bits, and the array has a size prefix, so it can be
> extended on demand? Public functions only use pointer+size then...
It's not about how to do a new ABI. It's about when and who does it.
- Very certainly not in 3.6.
- *Maybe* in 3.7.
- Do we have a volunteer creating a patch?
Corinna
More information about the Cygwin
mailing list