DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 524CAdmd3404769
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 524CAdmd3404769
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=RVcBcPH5
X-Recipient: archive-cygwin@delorie.com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AEFCA3858C60
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1741090237;
	bh=arZMPGBd/cfsfRZi4vhI8pLUbYPm8GbtRVUusYqGgzM=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=RVcBcPH5XRGHp+EY9JGP1UEw4aYB8iHeWa8srdjobOVK0EQOIb6zTi371LOb0STuA
	 rkQQ0R0F6flHdB5VlelpSbbraDDDPIvXIv4mkMgVEeiBtsnAhpUuRceFS3L2nC7WJT
	 qIViEMSB84vZMtA+Ty7sXR1l7M+BXExBeDXUsMtI=
X-Original-To: cygwin@cygwin.com
Delivered-To: cygwin@cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6FD513858D21
Date: Tue, 4 Mar 2025 13:10:09 +0100
To: cygwin@cygwin.com
Subject: Re: Cygwin 3.6: Supporting 128 POSIX realtime (SIGRTMAX-SIGRTMIN >=
 128) signals?
Message-ID: <Z8btoWzoxda66E9_@calimero.vinschen.de>
Mail-Followup-To: cygwin@cygwin.com
References: <CAPJSo4V-o3uXn7kFo1T93keo1w_SVTsGVEdycOfQDQC-L4KZCA@mail.gmail.com>
 <Z8WVxlEujfFlRrVn@calimero.vinschen.de>
 <CAPJSo4X0Vt3SafShOiQFNnR3oFCi2ZjRiutEMpeeyESp2XbtkA@mail.gmail.com>
 <Z8bRMfg87ZSWfscd@calimero.vinschen.de>
 <CAPJSo4VvuS6EQvwb8T4uZa=BJ2Nx4L6zVD7uvQiKp7cGx18qmw@mail.gmail.com>
 <Z8bmTHdZ8aDXXj9D@calimero.vinschen.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <Z8bmTHdZ8aDXXj9D@calimero.vinschen.de>
X-BeenThere: cygwin@cygwin.com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request@cygwin.com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-request@cygwin.com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request@cygwin.com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

On Mar  4 12:38, Corinna Vinschen via Cygwin wrote:
> 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?

For a quick overview what's involved in changing the ABI:

- Redefine sigset_t for newly built applications

- Redefine all datatypes containing a sigset_t, especially

    struct sigaction
    Cygwin's _cygtls TLS area

- Change the sigsetjmp/siglongjmp assembler code to work with
  new and old sigset_t definitions

- Create new versions of at least the following functions:

    sigaction
    sigaddset
    sigdelset
    sigemptyset
    sigfillset
    sigismember
    signalfd
    sigpending
    sigprocmask
    sigsuspend
    sigtimedwait
    sigwait
    sigwaitinfo

- Create functions to translate between old and new sigset_t/sigaction

- Change all of the above old functions to translate their sigset_t
  input or output to the new sigset_t and call the new functions.

- Make sure the old functions are only exported from the DLL, but not
  from libcygwin.a, and make sure the new functions are exported from
  libcygwin.a under the desired name.

So maybe you understand why this isn't lightly done.  It's a lot of
work with a lot of potential for breaking things thoroughly.  What's
really putting me off is the necessary change in sigsetjmp/siglongjmp.


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
