From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EB2C63857C48; Mon, 19 Jun 2023 18:54:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EB2C63857C48 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1687200897; bh=bRJ42+zDbMg1rockcPId1xHiQ0Rmh5VmxfhJ/NsTBe8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vSuZC84cenzipCepiy69ArpiwoRKaslWGpW6ZZhC+es/6+WVDm/CDADow+b1eX2dj pM281xWN/Js6U41dTD+uHhXwKcprAabNOuWYDznB2xK0PXOZvNJHhw9YJSp2w/Kv+B MFgd/CGNzGvzDZ82gfJcodzduLvr5Y4WzuusscmQ= 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 18:54:57 +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 #8 from Stas Sergeev --- Great news, thanks!. So within this RFC may I use the timer_getoverrun() safely? I suppose so, because there seem to be no more reentrancy into the handler ever possible, and also no one will call sigwaitinfo() until the handler is finished. That seems to be enough for timer_getoverrun() to work reliably. Also I think the signal-related problems are not available as internally SIGEV_THREAD_ID is used, so I suppose every thread receives only the signal from its own timer. So indeed such impl seems to mostly match what can be done with timerfd. > The glibc allows the created thread to be cancellable or call pthread_exi= t, > and it is not fully specified how the POSIX timer should act in this case. Maybe you can assign the thread destructor with pthread_key_create(), which would then re-create a thread? But there is more to it actually... https://pubs.opengroup.org/onlinepubs/007904975/functions/timer_create.html Quote: If a timer is created which has evp->sigev_sigev_notify set to SIGEV_THREAD= and the attribute pointed to by evp->sigev_notify_attributes has a thread stack address specified by a call to either pthread_attr_setstack() or pthread_attr_setstackaddr(), the memory dedicated as a thread stack cannot = be recovered. The reason for this is that the threads created in response to a timer expiration are created detached, or in an unspecified way if the thre= ad attribute's detachstate is PTHREAD_CREATE_JOINABLE. >From here we see that posix actually enforces the current glibc behavior, except when PTHREAD_CREATE_JOINABLE is specified via evp->sigev_notify_attributes. One way to do the job, retain the full compatibility and posix compliance, is to actually implement a proper way of handling PTHREAD_CREATE_JOINABLE case. Which would be only 1 joinable thread. Of course posix specifies timer_create() with multiple breakages, so what you do (ignore posix) is also perfectly reasonable in my eyes. Whatever way you choice, it would be good to write that posix are moro... to open a DR to The OpenGroup. --=20 You are receiving this mail because: You are on the CC list for the bug.=