From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5D3A63858D37; Thu, 20 Jan 2022 15:32:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5D3A63858D37 From: "ulatekh at yahoo dot com" To: glibc-bugs@sourceware.org Subject: [Bug librt/28799] New: [Feature request] Enhanced timer_create()/timer_delete(), for MS Windows parity Date: Thu, 20 Jan 2022 15:32:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: librt X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ulatekh at yahoo dot com 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 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 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2022 15:32:04 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28799 Bug ID: 28799 Summary: [Feature request] Enhanced timer_create()/timer_delete(), for MS Windows parity Product: glibc Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: librt Assignee: unassigned at sourceware dot org Reporter: ulatekh at yahoo dot com Target Milestone: --- I=E2=80=99m in the middle of porting a very large legacy code base from MS = Windows to Linux. One outpoint I've run into is in timer_delete(); there's no way to determine when no more callbacks are forthcoming. This makes it impossible to clean up safely after deleting a timer, especia= lly if the value passed in struct sigevent's sigev_value.sival_ptr is dynamical= ly allocated, e.g. a C++ object. The MS Windows API call DeleteTimerQueueTimer(), and even the ancient timeSetEvent(), allow for notification that there will be no forthcoming ti= mer callbacks. It pains me to see Linux not having an answer to anything MS Windows can do, and the fix is easy (though it'll require an updated API, like timer_create2()/timer_delete2() or something, if one chooses to follow ffmp= eg's convention when APIs are updated.) --=20 You are receiving this mail because: You are on the CC list for the bug.=