From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id a4127ca2 for ; Sat, 15 Feb 2020 17:27:42 +0000 (UTC) Received: (qmail 5997 invoked by uid 550); 15 Feb 2020 17:27:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 5970 invoked from network); 15 Feb 2020 17:27:39 -0000 Date: Sat, 15 Feb 2020 12:27:26 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200215172726.GP1663@brightrain.aerifal.cx> References: <19e6adf5.abdf.170487c3154.Coremail.zuotingyang@126.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19e6adf5.abdf.170487c3154.Coremail.zuotingyang@126.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] [timer] timer_delete function async problem On Sat, Feb 15, 2020 at 06:54:23PM +0800, zuotina wrote: > Hi everrone > > > Problem: > When I created SIGEV_THREAD timer, then start it by timer_settime. like this > the notify callback in the helper thread 'start' will be run when timer expiration. > But when I delete the timer, the notify callback will be run all the same. > This is not what i want. In actual use, I encountered a problem. > > > I found that the 'timer_delete' function returns immediately after called. > The timer may not perform the delete action. Logically the timer is deleted before the timer_delete function returns. If the handler thread is still running a handler at the time, that will necessarily continue intil it exits; the specification makes no provision for timer_delete doing anything to already-running handler threads. Since the operations are inherently unordered, it's possible that a new handler physically starts running after the call to timer_delete is made but before the signal is sent; as far as I can tell this is not observable by the application (since there is no ordering). > In addition, the SIGEV_SIGNAL timer can be deleted after called the function. > So i think the function has different semantics for different types. But doing so does not stop the signal handler from running (and fundamentally couldn't). So I don't understand what your concern is. Is it just that the kernel timer resource still exists until the handler thread finishes? I don't think that's visible to the application except possibly in limiting the number of timers that can be created. > Is there a way to implement synchronously ? At some point I plan to drop use of kernel timer resources entirely for SIGEV_THREAD timers, since they can be implemented *more easily*, with fewer hacks (no SIGTIMER at all! we can get rid of this reserved RT signal) with just a loop performing clock_nanosleep. If/when this change is made, there will be no kernel timer resource involed at all, so if I understand what you're asking, I guess that would give the behavior you want. (?) If I'm not understanding what you're asking for, could you send a minimal testcase program demonstrating how you observe a behavior you consider wrong without the test invoking any UB? Rich