From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id E357520C3B for ; Fri, 2 Aug 2024 16:21:21 +0200 (CEST) Received: (qmail 26368 invoked by uid 550); 2 Aug 2024 14:21:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26330 invoked from network); 2 Aug 2024 14:21:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722608468; x=1723213268; darn=lists.openwall.com; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:reply-to:from:subject:message-id:from:to:cc :subject:date:message-id:reply-to; bh=Z/amQfq9Ggyz7RXH3cKGS5rhTP15IWB4UZM0FtiyS8E=; b=SlB2+WP4oWJ9mX6cj/1MIud+BNP96GLxOSs2HiG1fI2pRmuZB985U/G946iRjWtfn+ AGvPP456E7GrjJ5oLmJ5Vt0doZrgAUF+vYDcfRnvMNuDwq7kG24q9XQSUym7DSlcSjhh 0Vt19JwnK705+PVJmvmLrwW1BVwk7PzN1rDkdh1x54rugy8etugLkSX2QhUzbTEnqYci srPxTshgpiAKEc5DQwAVtfwX/BarrcezX0NPnK5LYpAKChpK/sxJjszKvegIrNpDIXIw yBNm47S0rQfhoDEOadDomyvk9n5n8+x7aZ6nI0uEiXSWAR6nKqroORNB/nXfb+Y+PBWZ uMQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722608468; x=1723213268; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:reply-to:from:subject:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Z/amQfq9Ggyz7RXH3cKGS5rhTP15IWB4UZM0FtiyS8E=; b=UVV4fhTkdB4Ovnx5XcRkn6btsx4CQqLQpjDa7dK9pdkou2lqWO/7xYxVczowjLp1f5 fEuSwi6Ja36AGOKmKfzhRe6DnRpungvoetL3QpFy9rvIQr9NkWd+U3pOAKA5rB9o6J+5 1IaeLJBkzjEgyDo2OLB//9y4Mfdn8CG/mypM5X4YL72V4kG4vLkANeXmF0cxwPQLraqk mtQY4UmKVaZqYs3wOS5LhF6WHO8AMmbY9/NXoaKkhyuFKc+xR9BGP9sctD//Z+PTGszg VUyq4p+gFH6Li36kiwkIFclQH8NhrjdVVnN9tTnKoJbqhldlYwEiKkMxHAwXbKcmKdPo Lw1g== X-Gm-Message-State: AOJu0YykPBhMbjCxPWxB5yfzY6AoE8Z14oKzQaPh2GIFaX8w1kU7HBUI eAUXrizieCM8JQ9nt4+bMiUsIeMh70jGoN4VqRZWUt8XGFHuqil8T/+wHQ== X-Google-Smtp-Source: AGHT+IHi/fcNyEWBpTbLA2ToCrjU5lh7uKWqez7iKVRS10mduq28MjaZYt8iuu6u5+tEtsw8Vr7zVQ== X-Received: by 2002:aa7:c510:0:b0:57d:669:caf2 with SMTP id 4fb4d7f45d1cf-5b7f521e086mr3256881a12.25.1722608468185; Fri, 02 Aug 2024 07:21:08 -0700 (PDT) Message-ID: <2f9bbd9a289df7c7948ec410b364be4aae75d633.camel@gmail.com> From: Daniele GMail To: Rich Felker Cc: musl@lists.openwall.com Date: Fri, 02 Aug 2024 16:21:05 +0200 In-Reply-To: <20240802140456.GT10433@brightrain.aerifal.cx> References: <20240802140456.GT10433@brightrain.aerifal.cx> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 Subject: Re: [musl] pthread_sigqueue implementation On Fri, 2024-08-02 at 10:04 -0400, Rich Felker wrote: > On Fri, Aug 02, 2024 at 03:54:02PM +0200, Daniele GMail wrote: > > Hi, > > don't know if this is the right place to ask the question, if it's > > not, > > I'd hope someone points me out to the right list. > >=20 > > I'm working on the porting of a C multithreaded application which, > > up > > to now, was running on GLibC based Linux distros. Such application > > is > > using the method pthread_sigqueue in order to deliver signals to > > certain threads and AFAICS, it is not present in 1.2.5 release. > >=20 > > I see a discussion about the implementation dated back to 2020: see > > https://www.openwall.com/lists/musl/2020/02/05/5 > >=20 > > Would it be possible to reconsider the decision to drop the method? > > If not, do you have suggestions about what could be used in place > > of > > it? >=20 > I don't think it was really dropped, but things around it were just > never resolved. I re-read the thread and my main concern would be > namespacing, that it's not _np suffixed, while only glibc and recent > Solaris (or whatever it's called now) implement a function by this > name. >=20 > I think it would be noncontroversial to add with _np suffix, where > applications could probe for that and use it (or do their own #define > pthread_sigqueue pthread_sigqueue_np or whatever) if they need the > functionality. But I don't want to get locked into a situation where > we've added something POSIX may later define with possibly subtle > differences in signature or semantics. >=20 > Alternatively, if anyone wants to go ahead with proposing this as an > addition to POSIX, having it approved for POSIX-future with matching > signature and behavior should make it fine to add under the existing > name. >=20 > Rich If the problem is the namespacing only, I'd say that having the _np is super ok. For us it'd really be great if the method is implemented in the next releases. Daniele.