[Bug libc/30287] New: sigevent needs a notification method compatible with poll
bugzilla at tecnocode dot co.uk
sourceware-bugzilla@sourceware.org
Wed Mar 29 15:54:32 GMT 2023
https://sourceware.org/bugzilla/show_bug.cgi?id=30287
Bug ID: 30287
Summary: sigevent needs a notification method compatible with
poll
Product: glibc
Version: unspecified
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: bugzilla at tecnocode dot co.uk
CC: drepper.fsp at gmail dot com
Target Milestone: ---
I was recently trying to use `getaddrinfo_a()` to do asynchronous name lookups
in a library (GLib), and found that tying it in with a `poll()`/`epoll()`-based
main loop was quite hard.
sigevent currently provides two notification mechanisms: `SIGEV_SIGNAL` and
`SIGEV_THREAD` (I’m ignoring `SIGEV_THREAD_ID` because it’s basically just a
signal).
`SIGEV_SIGNAL` is not usable from libraries because to do so requires modifying
the process’ signal mask, which could impact on code outside the library, or on
spawned subprocesses.
`SIGEV_THREAD` spawns a new thread (via `pthread_create()`) for every return
from `getaddrinfo_a()`, which works but is not very performant.
Would it be possible to add an additional notification mechanism which writes
to a given FD, or something like that? Then that could easily be integrated
into the `poll()`-based main loop which is common to many libraries
(particularly those built around GLib, but also others) by passing one half of
a `pipe()` to sigevent.
Or perhaps another notification mechanism which just calls a provided function
and passes it an arbitrary user-supplied context pointer, and makes no
guarantees about the function execution context/thread? Then the user-supplied
function can do whatever it needs to to call back into the rest of the user
code in a thread-safe manner. This would be like `SIGEV_THREAD`, but calling
the user-provided function without `pthread_create()` first.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Glibc-bugs
mailing list