From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C1E5B3858D39; Tue, 20 Jun 2023 12:49:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C1E5B3858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1687265387; bh=woOrEe+UqcpfVe8LO9Sk9jn/I7PPq8Ks2ajBHaOLC1I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ftMMIGQ5riNhI3CGPdkegykdU03aLUFtwE3aCaLjcZG70IEzKX5IV58nJMNeDY3by OjozTxKID1p2+8j2t/STPUTwsRlbCf5/kLg1lyrYwmvftRGMiXzYeHuyYZiWp5YJZm w8cCcLz0FfDyUF5wY8e7z17TYAsLr1VUS4mD9CHA= From: "stsp at users dot sourceforge.net" To: glibc-bugs@sourceware.org Subject: [Bug libc/30558] SIGEV_THREAD is badly implemented Date: Tue, 20 Jun 2023 12:49:47 +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: stsp at users dot sourceforge.net 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 #19 from Stas Sergeev --- > I don't think so, the earlier quote (which you linked from the previous P= OSIX > version by the way, although it has not changed on POSIX 2017) allows both > implementations. This: [quote] the threads created in response to a timer expiration are created detached,= or in an unspecified way if the thread attribute's detachstate is PTHREAD_CREATE_JOINABLE. [/quote] I don't understand how it allows something else. If there are "threads created in response to a timer expiration", then obviously that means every timer expiration creates a thread. There can't be "threads created in response to a timer expiration" created only on *some* expirations but not all... > if the implementation is not subject to such issue it can ignore the 'may= fail'. Sure but that still defeats your claim that it advises against 1 thread per tick. It doesn't advice against, for sure. I see nothing that advises against or suggests otherwise, so could you please provide a quote that supports your point? Note: I am perfectly fine if you just tell "there is no such quote, but my impl is better so lets use it". Its perfectly fine, but saying posix allows it, is probably not fine unless it can be confirmed by a quote. > Not being joinable means that calling pthread_join() is UB. Hmm, ok. My definition differs, i.e. not being joinable means detached. Thanks for clarifying yours, I'll use it across this thread. --=20 You are receiving this mail because: You are on the CC list for the bug.=