[musl] pthread_sigqueue implementation

[musl] pthread_sigqueue implementation

[Daniele GMail]

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?

Thanks in advance,
Daniele.

Re: [musl] pthread_sigqueue implementation

[Rich Felker]

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

Re: [musl] pthread_sigqueue implementation

[enh]

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2514 bytes --]

Re: [musl] pthread_sigqueue implementation

[enh]

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

Re: [musl] pthread_sigqueue implementation

[Daniele GMail]

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

Re: [musl] pthread_sigqueue implementation

[Rich Felker]

On Fri, Sep 06, 2024 at 03:58:55PM +0200, Daniele GMail wrote:
> 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.

I'm looking back at the patch from
https://www.openwall.com/lists/musl/2020/02/05/5/1 for possible
inclusion (either in the _np namespace or as-is) and it seems to be
missing the signal blocking pthread_kill has, which is needed to
access the killlock safely. Oddly it still has the "set" local, which
is unused, so it looks like this was intentionally removed..? I think
it should just be added back, and then we should figure out which
name(s) this should be added with..

Rich

Re: [musl] pthread_sigqueue implementation

[Daniele GMail]

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.