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,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, 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 C998B22520 for ; Fri, 2 Aug 2024 16:14:01 +0200 (CEST) Received: (qmail 5166 invoked by uid 550); 2 Aug 2024 14:13:57 -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 5121 invoked from network); 2 Aug 2024 14:13:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722608028; x=1723212828; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ugEoUCyoejWKPauvJnaFgMbcQvH4cj2COUNK61nVQXo=; b=p7GaxjOGmZBlyxnLSR59XTRfPNzI7aOIgRr3tMagbcgcVkNRWSRD5jX/Ct2Le5J7/e f7o0Cfm1VqEaaUhFFYJ0vy0G6/cja3gMqaQtLHN4aEZWb0UhQ2spDxE1jp9zFKBjWRdd qy1QUypiDXk5DotuJtOGp2IPfLDUUyrfmPjmQgXAf2Mli+xdC7txBsQfDzfp9+zehiDg im9aNrBGvX64ej3+Mb2i84WU/Q8eBOfKfrxxWUvub2wgUzax+HFGkYGQTEcLm50SGF1g RKMkHIzC1KgOMqRMF0DODdTtxjY4/MdbcHbWMq/oP/q6ud78Qb00KnAHqaiTGSaNzEXC vQsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722608028; x=1723212828; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ugEoUCyoejWKPauvJnaFgMbcQvH4cj2COUNK61nVQXo=; b=lMWnfQWGlfqlKFGfhFrgmBp9YgQOn7Np3Ds8Ih86JOQs9kC8JEOiJGL/cKLuZQzBtx MZLtPGdGsWPtgClAVEgV9brATwhDAxKZvX02VigSE/EIxca1qVXh7E8gzjlc8GQ17jgG JQszsUQTkUM1UkfH2jhMJyWedZblWzxT3OVG/iGBeACW+nrzCOTVe32hQ9zkiRGK3+h9 USzbNWD2fMnY7T0zG6Z017wexWrALH5FyRZwfyXzC630cP7Rpf3kdFuXWEI9/TLCSjeZ M/o2EqMDonvE9xbVDHwhG/KEKuuDfh0/66WNingiegh8dKuwerN8u0eriFlexUKtrOWs 9ZBA== X-Gm-Message-State: AOJu0Yw1aeZCFokpWUTVUwBARt/1yvUVt24KkQ09vfTu5DVwbRsBjSU3 AZh0VnEaUB0MNrrTPQl7pZ45m43KIk7r2YE5PY9soDl0FJRGfqzl21w6UHKr7M6aV3c9KZpjUrS N8E48LmkpRk+8sPxl2DDrbFzGYYzWbmR5/9tUukGqVcN82cC0/g== X-Google-Smtp-Source: AGHT+IFuGL26bU0t/gtEbQFrY03x/GHGuhNyD4ViCOBFzYakAwGz5ULXoDvcBKSHQ7lu/rdKxITflePkSQWEDrY/y18= X-Received: by 2002:a05:6820:2207:b0:5c4:68b8:e27f with SMTP id 006d021491bc7-5d663ac4e53mr4705799eaf.6.1722608027735; Fri, 02 Aug 2024 07:13:47 -0700 (PDT) MIME-Version: 1.0 References: <20240802140456.GT10433@brightrain.aerifal.cx> In-Reply-To: <20240802140456.GT10433@brightrain.aerifal.cx> From: enh Date: Fri, 2 Aug 2024 10:13:30 -0400 Message-ID: To: musl@lists.openwall.com Cc: Daniele GMail Content-Type: multipart/alternative; boundary="0000000000009534f8061eb3efff" Subject: Re: [musl] pthread_sigqueue implementation --0000000000009534f8061eb3efff Content-Type: text/plain; charset="UTF-8" i haven't checked the source, but this implies it is in FreeBSD: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278459 On Fri, Aug 2, 2024, 10:08 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. > > > > 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. > > > > I see a discussion about the implementation dated back to 2020: see > > https://www.openwall.com/lists/musl/2020/02/05/5 > > > > 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? > > 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. > > 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. > > 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. > > Rich > --0000000000009534f8061eb3efff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i haven't checked the source, but this implies it is = in FreeBSD:=C2=A0https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278459=

= On Fri, Aug 2, 2024, 10:08 Rich Felker <dalias@libc.org> wrote:
O= n 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&#= 39;s not,
> I'd hope someone points me out to the right list.
>
> 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<= br> > using the method pthread_sigqueue in order to deliver signals to
> certain threads and AFAICS, it is not present in 1.2.5 release.
>
> I see a discussion about the implementation dated back to 2020: see > https://www.openwall.com/lists/musl/= 2020/02/05/5
>
> 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?

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.

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.

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.

Rich
--0000000000009534f8061eb3efff--