From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AA7DC3858D35; Thu, 22 Jun 2023 02:57:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AA7DC3858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1687402669; bh=WbCccYxHyzD8t2CGLxtqr1881RKOqJHd5esL6xPaYRc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=F2271gmtcI522QCRJg4fJD59D8nnwEWFY/7uCpbkVBu7ynL7titeEoh7dPTbXCWkA DemuoA325iovQMkCEnk2QaHsyAcxjC8SbWi7vaMsXFWNmosYJcn574fG8sdp9pUsYN IRYzdZgJd0em4XdPMssBqPou/8kEjhN1gJ73S0Gs= From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug libc/30558] SIGEV_THREAD is badly implemented Date: Thu, 22 Jun 2023 02:57:48 +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: bugdal at aerifal dot cx 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: cc 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 Rich Felker changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugdal at aerifal dot cx --- Comment #28 from Rich Felker --- FWIW, I think I do read the specification as requiring a "new thread" for t= he timer expiration event, but this does not conflict with an implementation choice to reuse the memory and kernel task from a previous thread *after its lifetime has ended* to provide the "new thread". This is what we do in musl. This does of course preclude delivering a second timer event while the prev= ious one is still running (yielding overruns). I view that a as a very positive = QoI property since it prevents cascading resources usage leading to exhaustion = and failure under load, and lets the application handle the overruns in some reasonable way instead. But if you did want to allow concurrent expiration functions on the same timer, the timer thread could attempt to first create= a real new thread, and only fallback to running the function in its own conte= xt when there are insufficient resources to make a new thread or some implementation-chosen concurrency limit is reached. --=20 You are receiving this mail because: You are on the CC list for the bug.=