Re: [musl] pthread_sigqueue implementation

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

Good day,
sorry to bother you, I know you have a lot of things boiling and this
is just another one on the pile.

But since I didn't see any other mail related to this thread I just
wanted to know if I can contribute in some way to help.

Thanks in advance,
Daniele.

On Fri, 2024-08-02 at 13:38 -0400, enh wrote:
> 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@google.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@libc.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