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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
