[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f9bbd9a289df7c7948ec410b364be4aae75d633.camel@gmail.com>
Date: Fri, 02 Aug 2024 16:21:05 +0200
From: Daniele GMail <d.dario76@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: pthread_sigqueue implementation
On Fri, 2024-08-02 at 10:04 -0400, 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
If the problem is the namespacing only, I'd say that having the _np is
super ok.
For us it'd really be great if the method is implemented in the next
releases.
Daniele.
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.
