[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZor7U1YOUR3BfJcYRfg91oV6WzteVOMZc9d=3oB0VfqddA@mail.gmail.com>
Date: Fri, 2 Aug 2024 10:13:30 -0400
From: enh <enh@...gle.com>
To: musl@...ts.openwall.com
Cc: Daniele GMail <d.dario76@...il.com>
Subject: Re: pthread_sigqueue implementation
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@...c.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
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
