mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] pthread_sigqueue implementation
@ 2024-08-02 13:54 Daniele GMail
  2024-08-02 14:04 ` Rich Felker
  0 siblings, 1 reply; 6+ messages in thread
From: Daniele GMail @ 2024-08-02 13:54 UTC (permalink / raw)
  To: musl

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [musl] pthread_sigqueue implementation
  2024-08-02 13:54 [musl] pthread_sigqueue implementation Daniele GMail
@ 2024-08-02 14:04 ` Rich Felker
  2024-08-02 14:13   ` enh
  2024-08-02 14:21   ` Daniele GMail
  0 siblings, 2 replies; 6+ messages in thread
From: Rich Felker @ 2024-08-02 14:04 UTC (permalink / raw)
  To: Daniele GMail; +Cc: musl

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [musl] pthread_sigqueue implementation
  2024-08-02 14:04 ` Rich Felker
@ 2024-08-02 14:13   ` enh
  2024-08-02 17:38     ` enh
  2024-08-02 14:21   ` Daniele GMail
  1 sibling, 1 reply; 6+ messages in thread
From: enh @ 2024-08-02 14:13 UTC (permalink / raw)
  To: musl; +Cc: Daniele GMail

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [musl] pthread_sigqueue implementation
  2024-08-02 14:04 ` Rich Felker
  2024-08-02 14:13   ` enh
@ 2024-08-02 14:21   ` Daniele GMail
  1 sibling, 0 replies; 6+ messages in thread
From: Daniele GMail @ 2024-08-02 14:21 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [musl] pthread_sigqueue implementation
  2024-08-02 14:13   ` enh
@ 2024-08-02 17:38     ` enh
  2024-09-06 13:58       ` Daniele GMail
  0 siblings, 1 reply; 6+ messages in thread
From: enh @ 2024-08-02 17:38 UTC (permalink / raw)
  To: musl; +Cc: Daniele GMail

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [musl] pthread_sigqueue implementation
  2024-08-02 17:38     ` enh
@ 2024-09-06 13:58       ` Daniele GMail
  0 siblings, 0 replies; 6+ messages in thread
From: Daniele GMail @ 2024-09-06 13:58 UTC (permalink / raw)
  To: enh, musl

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-09-06 13:59 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-08-02 13:54 [musl] pthread_sigqueue implementation Daniele GMail
2024-08-02 14:04 ` Rich Felker
2024-08-02 14:13   ` enh
2024-08-02 17:38     ` enh
2024-09-06 13:58       ` Daniele GMail
2024-08-02 14:21   ` Daniele GMail

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).