Re: [musl] pthread_sigqueue implementation

[enh <enh@google.com>]

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