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