From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 20C0B3858D1E; Mon, 19 Jun 2023 21:58:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 20C0B3858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1687211919; bh=B+qHH7ECGcVlaFdbm0XMCntbnt0uEyRoEprJ9rBN+ok=; h=From:To:Subject:Date:In-Reply-To:References:From; b=c6inQN/e0GSq+uZje1glOW+I8tSJffFqRPaEaSxfuavf4RXRluPyfYUSQmmp/vNW/ ejUA1FqBtxQZbKnHebsH4b/jNs/ZflAb10gf1b4G9L2KUD3toKqIbskcISKPJuSJX9 fGVc3S6+s9282BjEuvC8bCD/mc4MpAeiCrWFmFos= 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 21:58:38 +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 #15 from Stas Sergeev --- > Indeed afaik Linux reset the overrun time on each sigtimedwait syscall. Its not linux, its posix who defined timer_getoverrun() in an entirely crazy way of measuring underruns between signal queue and dequeue. Linux is at least making this more or less viable by actually measuring between dequeues only. Linux itself clearly says how it see it implemented: timerfd, where read() just resets the overrun count. Linux is written by skilled programmers, while posix is written by a mediocre doc-writers. > In fact, POSIX also advises against it on the timer_settime application > because of the concurrent stack usage issue [2]. Quote: [EINVAL] The it_interval member of value is not zero and the timer was created w= ith notification by creation of a new thread (sigev_sigev_notify was SIGEV_THRE= AD) and a fixed stack address has been set in the thread attribute pointed to by sigev_notify_attributes. So concurrent stack usage is explicitly disallowed, which means a detached thread per timer tick, as was said in the prev quote that I provided. > But POSIX explicitly states that the thread is *not* joinable > ("In neither case is it valid to call pthread_join()") I don't think it means not joinable. I think it means only that the _user_ should never call pthread_join() on such thread. Presumably he could do that by exporting its pthread_self() through the global variable. I think the thread itself can be joinable, and as long as the user doesn't call pthread_join() on it, things are good and glibc itself *can* (and should) call pthread_join() internally on a timer destruction. > In fact, from the Austin issue [1] the next POSIX 2018 defined that provi= ding > a pthread_attr_t with joinable state is undefined-behavior [2]; This only confirms that posix is written by idiots. But such an obvious fact probably doesn't need so many confirmations. :) > so I am even more inclined to *not* move to make it implementation-define= d. I am definitely not "insisting" in any way. I am only pointing out that any other approach is even more problematic. But at the end, any improvement is better than the current mess. What do you think about opening a DR to The OpenGroup? If it would be me, I wouldn't resist saying who they are, so its better be you. :) Though I don't think timer_create() API can be vindicated by a DR or 2. getoverrun is also completely broken, and so on. Why I still have to use it, is only because of freebsd. On linux my app uses timerfd, of course and for sure. I am trying to avoid the brain-damaged posix APIs on linux, but there comes freebsd... --=20 You are receiving this mail because: You are on the CC list for the bug.=