From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2D1173858C50; Wed, 29 Mar 2023 15:54:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2D1173858C50 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1680105273; bh=DHbaSSR+FqkaKxkQAymzDMtrrmztR7v5Xb4MR76a1a0=; h=From:To:Subject:Date:From; b=AwFfBy3jKlup3T2l1P0B8URCgt6KmKeyR2VMFmLAGkucKnZi5uKBQKTXCV42qzLK7 4DoKpLuLGkmHeCkDj6YXlWGKfFILD3wQJOvqTtkuABpsZKfETMdCQbRLbsWQcWf+sb wkPi2KyKnIHTjrAKxrQNdi448GDM+cnz/WFCXUdg= From: "bugzilla at tecnocode dot co.uk" To: glibc-bugs@sourceware.org Subject: [Bug libc/30287] New: sigevent needs a notification method compatible with poll Date: Wed, 29 Mar 2023 15:54:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: bugzilla at tecnocode dot co.uk X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30287 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 look= ups in a library (GLib), and found that tying it in with a `poll()`/`epoll()`-b= ased main loop was quite hard. sigevent currently provides two notification mechanisms: `SIGEV_SIGNAL` and `SIGEV_THREAD` (I=E2=80=99m ignoring `SIGEV_THREAD_ID` because it=E2=80=99s= basically just a signal). `SIGEV_SIGNAL` is not usable from libraries because to do so requires modif= ying the process=E2=80=99 signal mask, which could impact on code outside the li= brary, 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 writ= es 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 funct= ion and passes it an arbitrary user-supplied context pointer, and makes no guarantees about the function execution context/thread? Then the user-suppl= ied 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=