|
Message-ID: <CAJgzZoqqqCRZH84MoWsCMpTpso8qAn2Z2PtqoU2W4PXM20SJKQ@mail.gmail.com> Date: Fri, 2 Aug 2024 13:38:41 -0400 From: enh <enh@...gle.com> To: musl@...ts.openwall.com Cc: Daniele GMail <d.dario76@...il.com> Subject: Re: 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 AM enh <enh@...gle.com> wrote: > > 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 <dalias@...c.org> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.