From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7635A3858D39; Mon, 19 Jun 2023 21:15:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7635A3858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1687209329; bh=3GnXIX2Y4Dc4I8na35X/+yvE1sCDY0kJ46a7KZbe4ng=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Wl+pYVQ+QHV19pPDNrgKAs6Lc/OxEjWOH+5J1Jc79KMz9wGNPWOAMlvbs3p/oytYU 7mWgGkZB2juAL6A9kLE4ZpR41zzGsdzVNwAyH3Jv3OOK1GI4rvpSERhd/o4cjERYfN KIoxc5PcmiHVzMjd5E81nEUKNTwEQwYKI3q+btDs= 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 21:15:29 +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 #13 from Adhemerval Zanella --- (In reply to Stas Sergeev from comment #12) > > And since it is the kernel that keep track of the overrun, the reentran= cy > > issue is not really related on the overrun itself, but rather on the si= gval > > argument. >=20 > Overruns are measured between signal queue > and dequeue. Linux fixes that scheme by > actually measuring between 2 subsequent > dequeues AFAIKS, though doesn't matter. > What matters is that, because of reentrancy, > the handler will query the overruns after > another signal was already delivered, so > the result would be a complete garbage. Ok, I now see what you mean here. Indeed afaik Linux reset the overrun time= on each sigtimedwait syscall.=20=20 >=20 > > My understanding from the quote you borght is not that it is specified > > that concurrent threads are allowed or not >=20 > Let me quote again then: > [quote] > the threads created in response to a timer expiration are created detache= d, > or in an unspecified way if the thread attribute's detachstate is > PTHREAD_CREATE_JOINABLE. > [/quote] >=20 > Three things are being said here: > 1. Threads are created in a response to every timer expiration Reading the SIGEV_THREAD description [1], it is not clear to me that a new thread should be created for *every* timer expiration from the same timer. = In fact, POSIX also advises against it on the timer_settime application becaus= e of the concurrent stack usage issue [2]. So, the current scheme has the additional drawback that a user-specific stack is really not safe. > 2. They are detached > 3. The user can specify PTHREAD_CREATE_JOINABLE, in which > case the behavior is implementation-specific. >=20 > I propose to use 3 as a base for implementing > PTHREAD_CREATE_JOINABLE case first, then see > what remains. But POSIX explicitly states that the thread is *not* joinable ("In neither = case is it valid to call pthread_join()"), and as I said it makes even tricker to handle the per-timer thread (what happens to the timer after the thread is joined? Should pthread_join issue timer_delete? What happens if there threa= d if cancelled or issue pthread_exit?). [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.ht= ml [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/timer_settime.ht= ml --=20 You are receiving this mail because: You are on the CC list for the bug.=