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=-2.9 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,T_SCC_BODY_TEXT_LINE 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 39C8F2D6CC for ; Fri, 6 Sep 2024 15:59:11 +0200 (CEST) Received: (qmail 15642 invoked by uid 550); 6 Sep 2024 13:59:07 -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 15604 invoked from network); 6 Sep 2024 13:59:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725631138; x=1726235938; darn=lists.openwall.com; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:reply-to:from:subject:message-id:from:to:cc :subject:date:message-id:reply-to; bh=SH+oD9E40++bS2njDjLgnWXw9FHSm/35NKWN5UkUmHY=; b=MrMfHiY8JXhACnFHNLq/dI9wipd871Y2R4VvAbx9fCNwkl6u8mPJmUyngRULzgkcow 72PPcaJhQqTRvKA6l2wELlNNKDKAyJsa5xrwHtwCZWPK6zXPLad2/jquYA2YT5Jp50zm OLbe9RTpl7pFfhkA6tvrg+IKdBleT0H8v2NIzL1dRkCxd6ACW2+uZVH2NUyG53ysi4Hq nntohuzVOi04HJkFKvX2qNpQzVvum8ZyBruKW8y9VIfy4VObfCUxHMHqRh4pknnsm45v MdhrZb2nnUJ+HHr6F8oO1dLWcFRpmt99hL4GvUfUSat2A+363Y97dJG9I+ol78gx+6rP gJJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725631138; x=1726235938; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:reply-to:from:subject:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SH+oD9E40++bS2njDjLgnWXw9FHSm/35NKWN5UkUmHY=; b=ScqL+RcrO2uZSf7EqaWze1bpTV7SoWm+RXiD9WnPRO9Q5af+S10BCx1Tb0PaIgBi15 z6U9NLF1WGm+UXixJuJDePEmYPEoB8+IuxeFmfu7K6dllw8lyaJinUntiyfpFM8FhCRm r6Vn36GaxD6eMsPMp9u6uW0fbRCdFNSfF6QYZ8/zk8XE1OIxEyp98VP7nu/2R6beoz7G 56RInvBgY7zNXc4zj4NsBIgceddpNiuXAyzFqpAUbiKc5xlGdRMSg/djZ5x/VVt/SuOS fpRBDWg7xNIgFFHzg8TxH0N2be73SN0tq5li63ElRkHMkQEUYcPvf5fen/cTfI+YQ7Ot 1RFw== X-Forwarded-Encrypted: i=1; AJvYcCXi8XCy3ohijdOgybpfxHo4edKRAF1BYtnvuvZFsvo5Y+Tt716vkssI5x48hhrBQ8RVB63q@lists.openwall.com X-Gm-Message-State: AOJu0YxxO1PQKbu8G7ipDI0z2D/4+eZobPIGp4S+eGNySqD48lSTBS1j aT752E9xHQbV2yTpxkM9w6PpLVzZnPUBdi411x03uPKM5YiSZprB X-Google-Smtp-Source: AGHT+IGq8Q36mTzmxSU9Xm1ysA+aRu4TmdlWPzdW0oaB8ALFhz8K98dNkEkElBu6Umuz3YQlXcXqvQ== X-Received: by 2002:a17:907:25c8:b0:a8a:86a9:d6e2 with SMTP id a640c23a62f3a-a8a8866c0bemr216413266b.37.1725631138030; Fri, 06 Sep 2024 06:58:58 -0700 (PDT) Message-ID: From: Daniele GMail To: enh , musl@lists.openwall.com Date: Fri, 06 Sep 2024 15:58:55 +0200 In-Reply-To: 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 Good day, sorry to bother you, I know you have a lot of things boiling and this is just another one on the pile. But since I didn't see any other mail related to this thread I just wanted to know if I can contribute in some way to help. Thanks in advance, Daniele. On Fri, 2024-08-02 at 13:38 -0400, enh wrote: > having now looked, yes, freebsd does have pthread_sigqueue(). >=20 > oh, and fwiw, bionic also has pthread_sigqueue(), also without the > _np... >=20 > funnily enough, FreeBSD marks it as a BSD extension for _BSD_SOURCE, > and bionic as a GNU extension for _GNU_SOURCE. >=20 > while macOS _does_ have an SI_QUEUE constant, they have neither > pthread_sigqueue() nor even sigqueue(). >=20 > On Fri, Aug 2, 2024 at 10:13=E2=80=AFAM enh wrote: > >=20 > > i haven't checked the source, but this implies it is in FreeBSD: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278459 > >=20 > > On Fri, Aug 2, 2024, 10:08 Rich Felker wrote: > > >=20 > > > 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