[Bug libc/30287] New: sigevent needs a notification method compatible with poll

["bugzilla at tecnocode dot co.uk" <sourceware-bugzilla@sourceware.org>]

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.