From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 18E8C385624C; Fri, 16 Jun 2023 06:44:05 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 18E8C385624C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1686897846;
	bh=38Q6f7v/EW+I5i860UqRGePuqru7RPPJ/7OxQT+cOys=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=nNap9uiwcHgLwr06r4wuozkxTZtRwaBGUGuil+sLZBHxw2e95kNRJGo+OjbgxSqkE
	 4CJyvbiO7UDE1vV++wX6UC1b/Ub96rAIVsDyx7vQ+v5IEpsRljvE8nDU8+2xutli7A
	 KELJog9IBLB21aJi7933rFe3BULhBW5gPBKlfKtA=
From: "stsp at users dot sourceforge.net"
 <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/30558] SIGEV_THREAD is badly implemented
Date: Fri, 16 Jun 2023 06:44:05 +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: <bug-30558-131-OhPoVq9jgJ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-30558-131@http.sourceware.org/bugzilla/>
References: <bug-30558-131@http.sourceware.org/bugzilla/>
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: <glibc-bugs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D30558

--- Comment #3 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Adhemerval Zanella from comment #1)
> FreeBSD also implements SIGEV_THREAD in the same ways as glibc: with a
> detached helper thread that spawns thread when kernel signal when thee ti=
me
> has expired (check
> https://github.com/freebsd/freebsd-src/blob/main/lib/librt/sigev_thread.c=
).

Hmm, looking into sigev_service_loop()
from this example, I don't even see the
synchronization. Am I right that after
sigwaitinfo() it just spawns the detached
thread and goes for another sigwaitinfo()?
Does this mean multiple threads can be
spawned concurrently if timer handler is
lagging?
If this is so, does glibc do the same?

--=20
You are receiving this mail because:
You are on the CC list for the bug.=