From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F1E2A3858D38; Tue, 20 Jun 2023 04:14:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F1E2A3858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1687234460; bh=SWVmKg1PXtTnksow0lcvMd1dIxaDMfWZEK9a3cjr0xA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XcLa3fR8BBamKq/D54MSPH2Llbawu2+81vdcEg8uWiQxoKwgevVi6X2tNr4XEmP4F PIu1+P7pqT2Iv3c1Sz7qp3tao3RPMOoeJu8XX7ct6ucKHxGw6i4MI/bVl2jm88bYnS n7777vrdPYIEq4yROJM5gEEb0oogcq1DQJHzg3TY= 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 04:14:20 +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 #17 from Stas Sergeev --- > This is defined as 'may fail', which does not bind the implementation > to the required semantic of one thread per time expiration. Still it is enough to make your other claim invalid: "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 bec= ause of the concurrent stack usage issue [2]." The earlier quote provided by me is very explicit on a thread per tick, and timer_settime doesn't advice against that because it even defines the failure per multiple stack usage. This means it foresee 1 detached thread per tick, rather than advicing against. So we have 1 explicit quote about that, and we have 1 that implicitly supports that. I'd say "posix is very clear on this". > This wording is a user-visible API, so not being joinable There is no such wording. The wording it: "In neither case is it valid to call pthread_join()" and you conclude it means not joinable. But it doesn't mean so. > And glibc does not need to join the thread But we were discussing the user-provided PTHREAD_CREATE_JOINABLE attribute. > Afaik POSIX only defines API after a de-facto implementation > exactly to avoid adding non-tested ones. Maybe that was modeled after some very old bsd impl, no idea. Linux would definitely not start from such an impl. It is visibly even trying to fix timer_getoverrun()'s definition, and then re-implements the whole thing in a timerfd. > A DR for what exactly? Exactly for proposing 1 detached thread per tick in the quote I pointed. And there were no quotes that say otherwise. Also they should explicitly disallow calling pthread_exit() and other things that musl disallow. Also they should realize that 1 thread per tick breaks timer_getoverrun(), and probably re-spec timer_getoverrun() completely. Or if they fail to do the above, then at least they should keep supporting passing a pthread attribute, rather than to declare that an UB (although this is not needed if they fix the rest). There are the reasons for a DR here. --=20 You are receiving this mail because: You are on the CC list for the bug.=