From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6B0923858D38; Mon, 19 Jun 2023 19:33:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6B0923858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1687203204; bh=lByKTivQqNVScwDzWPP4WpEQ9jXxb0AWArd/IJ4K6R0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=U/xMmkgLBy+6CZ0S3Dygc0VAxLDS21bXlvGiLIdjDlxl+fhZCFgLjHIxu4pmK8LZo MEze6isLnVL+q8LvC9fuCmZauO0+w1wgwoHPVJiz6E+GKg7HI0WnZ/s37l8b74mP45 MXekzaqn7oHeOF6WXKTzTFgRkA97onKoLx0sZAqE= From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug libc/30558] SIGEV_THREAD is badly implemented Date: Mon, 19 Jun 2023 19:33:24 +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: adhemerval.zanella at linaro dot org 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 #9 from Adhemerval Zanella --- (In reply to Stas Sergeev from comment #8) > 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. I don't see any reentrancy issue with the current approach, the background thread that issues sigwaitinfo is created with only SIGSETXID not masked. = So each sigwaitinfo will get one SIGTIMER from the kernel. My RFC, on the other hand, requires installing the SIGCANCEL handler. It w= orks because pthread_cancel does not actively sends the signal if the asynchrono= us mode is not set (I might revise if this work for my proposed fix for BZ#126= 83). >=20 > 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. >=20 > > The glibc allows the created thread to be cancellable or call pthread_e= xit, > > and it is not fully specified how the POSIX timer should act in this ca= se. >=20 > Maybe you can assign the thread > destructor with pthread_key_create(), > which would then re-create a thread? It would mean maintaining a list of SIGEV_THREAD timer_t so it updates the relation of timer_t -> kernel timer_t on each thread recreation. It would n= ot be possible to use the pthread_t as the key for timer_* operation, so we wi= ll always need to consult the data structure in such cases. I still prefer to = musl solution to intercept pthread_exit/pthread_cancel and do not act upon it. > But there is more to it actually... > https://pubs.opengroup.org/onlinepubs/007904975/functions/timer_create.ht= ml > Quote: >=20 > If a timer is created which has evp->sigev_sigev_notify set to SIGEV_THRE= AD > 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 > thread attribute's detachstate is PTHREAD_CREATE_JOINABLE. >=20 > 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. >=20 > Of course posix specifies timer_create() > with multiple breakages, so what you do > (ignore posix) is also perfectly reasonable > in my eyes. >=20 > Whatever way you choice, it would be > good to write that posix are moro... > to open a DR to The OpenGroup. In fact, POSIX defines a semantic that is not what glibc provides since cal= ling pthread_cancel on a detached thread is not really specified. One option is bring this on patch to state that trying to cancel the POSIX timer thread is UB, so we should not really support it. --=20 You are receiving this mail because: You are on the CC list for the bug.=