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, 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 70EFD2382F for ; Fri, 2 Aug 2024 19:39:10 +0200 (CEST) Received: (qmail 20197 invoked by uid 550); 2 Aug 2024 17:39:06 -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 20155 invoked from network); 2 Aug 2024 17:39:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722620337; x=1723225137; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=f28RZyMgmbYMX9z1z4ZwOqgCcp8uBt37pCqtBLt+laQ=; b=18SX9BxmUPjo2skLimTXO+QzsDRYYG5dl2REeb1VsL3rDfPgp0fyu05OaULZV9wb2w BhXOgT1ffJnT6S+p4YMzjkQHll1oH4i6urgL2zr7aHwDtwtj+wThyIAtAFdVSIuhex7W q5OUf805t9TazQPaJ1NdpAB3GH0iPTHBjrtW/nCHNSFmLsx4aFTxXaL2SNbVBEpDcm90 vDHyxO8OG06JM7Vtorn3aPXU4qD1GHzHz1y+SycyC80sRc6AYb2Mu+gnvkp6xP4GT/vm o3KXBV6HgEmbh/m1rLOB3g2p3IsnOxQRzn8OBiLNIHFqRDcepnT/c96mT1tx+Q+qcXTI ZnXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722620337; x=1723225137; h=content-transfer-encoding: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=f28RZyMgmbYMX9z1z4ZwOqgCcp8uBt37pCqtBLt+laQ=; b=WRuizFdNGxPTR1qftwOIwQRJCr/BGffi1mkKL++/IR1hgcDz1yRqMZFHYBE874gXCL mYeDRhHdxcLNSdOSn9Q3NgGgyIhemQhun7Ck3wV1pPl6qhfWt0qAZVVpHsS45+Wi0O0+ 5vz+d2tf2ZsSKNGsMFLn0b95IJLrBbsH1e5mDGg59G/ORj9jjylEMYZC5fx0jQpa7wjP O6dFIVo/gkNVqrwG74+J+7vbSgQxxN+6Nfjt7uA3A+k6dQmNXgLciLJQcJ8aQtqzuUjk nJ7sIFDtJmCHbCDHrwdbxb4Pw4hrKCwTt8GvMufOeABBJN8TdxDbYUY7yS7W5P4BhB3x KSKQ== X-Gm-Message-State: AOJu0Yzrw+kLtjqfwI1IzNoXkDhrYB1kK7O3Fs+RN0rn8rQkigDrw7OM OTB+7KHDS5PB6pt02l6df0IcCS1l7TukglCpX6SojLXRL06uiLwgpNoaiPuPPJDaeG3RaYFtvUE gL5Qi7x4lRwMfM/Q13foWeXGCRkeEkxcxyintp/o3O7UAPevWqgMY X-Google-Smtp-Source: AGHT+IHTSfvSh1ogcsuc1YPZSYWeL+x1soViwvtxLiXAYAflVeSvldigieoCY4yypH6pdGlaJ2cByGR/sdoZuoRNKB0= X-Received: by 2002:a05:6214:2b85:b0:6b7:a44c:c889 with SMTP id 6a1803df08f44-6bb98454588mr44632426d6.52.1722620336890; Fri, 02 Aug 2024 10:38:56 -0700 (PDT) MIME-Version: 1.0 References: <20240802140456.GT10433@brightrain.aerifal.cx> In-Reply-To: From: enh Date: Fri, 2 Aug 2024 13:38:41 -0400 Message-ID: To: musl@lists.openwall.com Cc: Daniele GMail Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] pthread_sigqueue implementation having now looked, yes, freebsd does have pthread_sigqueue(). oh, and fwiw, bionic also has pthread_sigqueue(), also without the _np... funnily enough, FreeBSD marks it as a BSD extension for _BSD_SOURCE, and bionic as a GNU extension for _GNU_SOURCE. while macOS _does_ have an SI_QUEUE constant, they have neither pthread_sigqueue() nor even sigqueue(). On Fri, Aug 2, 2024 at 10:13=E2=80=AFAM enh wrote: > > i haven't checked the source, but this implies it is in FreeBSD: https://= bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278459 > > 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