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
>