From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D9A533854E79; Fri, 16 Jun 2023 07:29:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D9A533854E79 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1686900576; bh=fvRw728SJ03iLR8zjSjH1LuqrGPeLGc+XTgxkdQPUbo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nOU6zTBpwZtrsKVfaqIYMPjjiw78QEhsv87dFygytXYaK70vo8jheLhK/kJGblzj5 mNoXNBi3lePxzAxA1qnaWyZGkZ2AriWDi7stXe64cxGJ95FeOnh2/M/Oz8RBjiPtmN xHUFfhRpcT7IiTX5+B3lAt7QquFappgbbNjgc54A= From: "stsp at users dot sourceforge.net" To: glibc-bugs@sourceware.org Subject: [Bug libc/30558] SIGEV_THREAD is badly implemented Date: Fri, 16 Jun 2023 07:29:36 +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 #4 from Stas Sergeev --- Yes, I used your example to check with glibc, and it appears it indeed spawns any amount of threads concurrently if the handler sleeps. But in this case I think that impl is not even posix-conforming because in that scheme you can't use timer_getoverrun() consistently. The man page of timer_getoverrun() explicitly says that the timer doesn't queue more than 1 signal, so that timer_getoverrun() can show the overrun count between signal queuing and dequeuing. To me that still looks crazy because after signal dequeuing another overrun could occur. But at least that scheme can be made working, because linux AFAICS "cures" that by adding such lost overruns upon the next signal delivery. But if you spawn multiple threads concurrently, how are you going to use timer_getoverrun() at all? --=20 You are receiving this mail because: You are on the CC list for the bug.=