|
Message-ID: <20240802140456.GT10433@brightrain.aerifal.cx> Date: Fri, 2 Aug 2024 10:04:57 -0400 From: Rich Felker <dalias@...c.org> To: Daniele GMail <d.dario76@...il.com> Cc: musl@...ts.openwall.com Subject: Re: 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
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.