[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 1 Aug 2019 12:15:57 -0400
From: James Y Knight <jyknight@...gle.com>
To: musl@...ts.openwall.com
Subject: Support SIGEV_THREAD_ID
There seems to be some debate in glibc over whether this API should be
supported, due to the long-standing debate about "pthread_t" vs
"kernel tid" APIs. (And this API uses kernel tids, of course.)
One proposal from previous glibc discussion was to add a
SIGEV_PTHREAD_ID, which takes a pthread_t, instead of a kernel tid.
Nobody has done this yet, and I'd note that if it is done, that is not
at all incompatible with also continuing to support SIGEV_THREAD_ID.
(Just like both sched_setaffinity and pthread_setaffinity_np exist
without issue).
Despite that discussion, SIGEV_THREAD_ID functionality does in fact
work with glibc -- it provides the SIGEV_THREAD_ID define in its
headers, and it defines the same 'struct sigevent' as the kernel does,
including a _tid member. The only thing it's missing is the field name
"sigev_notify_thread_id" -- so users are simply doing "#define
sigev_notify_thread_id _sigev_un._tid" as a workaround (ugh).
However, it does _not_ work today with musl, as musl's timer_create
function translates the user-facing struct to a separate kernel-facing
structure.
Given long-standing usage of this feature, and given that potential
future directions are additive, not conflicting, ISTM reasonable to
just add support for this to musl.
View attachment "0001-Add-support-for-SIGEV_THREAD_ID-and-sigev_notify_thr.patch" of type "text/x-patch" (2647 bytes)
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.
