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... Lionel -- 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
