From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 06C7E3858D1E; Mon, 19 Jun 2023 20:14:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 06C7E3858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1687205641; bh=0t+tj2ZLIE9j8I3izjywEdEh2qGCtLENN1f0FX+FSOI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hUHIVhCyAeMVQVLNX5dP2q9IoRupE/VhX1hVRmUJnpJqU9iftysA0F7qlCOxsZZUa nWsQB3xTJyRWK7D0CBTRhTX+r3UVllcx9J5gv94w12dKMbCDwPBdyEBR/Lu/YNHHaE lE4D+lRwM9EmDqD0Jj9pM6Jxc3MZoJTDg4zNwr6I= From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug libc/30558] SIGEV_THREAD is badly implemented Date: Mon, 19 Jun 2023 20:14:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.37 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org 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: Message-ID: In-Reply-To: References: 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=3D30558 --- Comment #11 from Adhemerval Zanella --- (In reply to Stas Sergeev from comment #10) > > I don't see any reentrancy issue with the current approach >=20 > But there is. > Its trivial to verify with your > own test-case posted here. You just > need to insert sleeps into the handler. >=20 > Which is why I made the above quote > from posix. It says explicitly that > a detached thread is created in response > to every timer expiration. > So it explicitly allows reentrancy and > deliberately breaks timer_getoverrun(), > and glibc was following that very precisely. Ah right, indeed current approach will trigger the callback function with provided arguments on each timer expiration while the new scheme will only issue the callback once the previous timer callback returns. Afaiu, POSIX = does not specify an semantic regarding it; it only specify that you need an over= run facility that you can query. And since it is the kernel that keep track of = the overrun, the reentrancy issue is not really related on the overrun itself, = but rather on the sigval argument. My understanding from the quote you borght is not that it is specified that concurrent threads are allowed or not, but rather that if the application allocates some memory to use as the thread stack it can not be reliably free since the thread is not joinable (it will eventually leak once timer_delete= is called).=20 And I don't think allowing the SIGEV_THREAD thread as joinable is also a go= od way forward. Besides breaking the standard, it means that timer_delete is n= ot the only point where you cancel the timer (worse, the kernel will continue = to trigger the timer since in this case there is no timer_delete syscall on the timer). We can add the timer_delete on thread exit / join, but the idea of = the per-thread timerid is that is only visible for the POSIX timer threads (pth= read code does not handle it). --=20 You are receiving this mail because: You are on the CC list for the bug.=