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.3 required=5.0 tests=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 EDF7627447 for ; Fri, 2 Aug 2024 16:08:34 +0200 (CEST) Received: (qmail 18193 invoked by uid 550); 2 Aug 2024 14:05: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 18102 invoked from network); 2 Aug 2024 14:05:05 -0000 Date: Fri, 2 Aug 2024 10:04:57 -0400 From: Rich Felker To: Daniele GMail Cc: musl@lists.openwall.com Message-ID: <20240802140456.GT10433@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] pthread_sigqueue implementation 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