From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 28CAB3858D3C; Mon, 19 Jun 2023 20:26:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 28CAB3858D3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1687206407; bh=BFtum0HMMaWpxNDdQRfEzQDdcue0R3DY/sM/3HCzP5Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qDtycbq+X5K7gQD/yJpkaI3NbE8ZX00fw/5msPH64aBl5PNzQuDe5ovr84gSNZRaL 3+W0AbTnMFlw0f9piDyBqp+i4v9iinjpH58jY2iWMeWFbVorefdRX1N3PV9rP0Wi/L /6Jbb6g9Yoktxqos3KY05eXicRNKqgfilYZv6AgE= From: "stsp at users dot sourceforge.net" To: glibc-bugs@sourceware.org Subject: [Bug libc/30558] SIGEV_THREAD is badly implemented Date: Mon, 19 Jun 2023 20:26:46 +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 #12 from Stas Sergeev --- > 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 sigv= al > argument. 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. > My understanding from the quote you borght is not that it is specified > that concurrent threads are allowed or not Let me quote again then: [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] Three things are being said here: 1. Threads are created in a response to every timer expiration 2. They are detached 3. The user can specify PTHREAD_CREATE_JOINABLE, in which case the behavior is implementation-specific. I propose to use 3 as a base for implementing PTHREAD_CREATE_JOINABLE case first, then see what remains. --=20 You are receiving this mail because: You are on the CC list for the bug.=