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

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

[bugzilla at tecnocode dot co.uk]

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.

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

[fw at deneb dot enyo.de]

https://sourceware.org/bugzilla/show_bug.cgi?id=30287

Florian Weimer <fw at deneb dot enyo.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2023-04-02
              Flags|                            |security-
                 CC|                            |fw at deneb dot enyo.de

--- Comment #1 from Florian Weimer <fw at deneb dot enyo.de> ---
Is timerfd_create sufficient for your purposes?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[bugzilla at tecnocode dot co.uk]

https://sourceware.org/bugzilla/show_bug.cgi?id=30287

--- Comment #2 from Philip Withnall <bugzilla at tecnocode dot co.uk> ---
I’m not sure how timerfd_create() helps; aiui to fix this, a new event type
would have to be added to the `SIGEV_*` types and supported internally by
sigevent.

In any case, I have worked around this problem in GLib by running the
synchronous getaddrinfo() in a local thread pool, so I am no longer attempting
to use getaddrinfo_a(). It seems like that API has a few too many caveats to
make it useful in my use case.

As such, feel free to close this issue if you think sigevent wouldn’t benefit
from additional API at the moment (I’m not sure how actively it’s used by
anyone). Thanks

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30287

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #3 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Philip Withnall from comment #2)
> I’m not sure how timerfd_create() helps; aiui to fix this, a new event type
> would have to be added to the `SIGEV_*` types and supported internally by
> sigevent.

You suggested:

> Would it be possible to add an additional notification mechanism which writes to a given > FD, or something like that?

timerfd_create seems to be just, a file descriptor that becomes ready once the
timer expires.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[bugzilla at tecnocode dot co.uk]

https://sourceware.org/bugzilla/show_bug.cgi?id=30287

--- Comment #4 from Philip Withnall <bugzilla at tecnocode dot co.uk> ---
`timerfd_create()` does emit a notification via an FD, yes, but I don’t see how
that could be hooked up to `getaddrinfo_a()` using existing APIs, so that it
efficiently emits its notification when the address lookup is complete.

That could be achieved by using `SIGEV_THREAD` and calling `timerfd_settime()`
from the thread function to fire the timerfd when the address lookup is
complete. That doesn’t solve the original problem, though, because it requires
a thread to be spawned to fire the timerfd. That’s not very performant, and
shouldn’t be necessary at all: firing a timerfd is basically a single bit
change in a data structure, not a complex block of work which should need to be
run in a separate thread.

-- 
You are receiving this mail because:
You are on the CC list for the bug.