Re: [musl] pthread_sigqueue implementation

[Daniele GMail <d.dario76@gmail.com>]

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.