From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: SIGPROF + SIGCHLD and igc Date: Sat, 28 Dec 2024 16:25:22 +0200 Message-ID: <86frm7sx4d.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <87ttaucub8.fsf@protonmail.com> <87pllicrpi.fsf@protonmail.com> <864j2u442i.fsf@gnu.org> <87a5ch5z1b.fsf@gmail.com> <87plld5pev.fsf@protonmail.com> <87ed1t6r34.fsf@gmail.com> <875xn46s6z.fsf@gmail.com> <86bjwwulnc.fsf@gnu.org> <877c7jlxsu.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18120"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 28 15:26:28 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tRXlp-0004Ut-L1 for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Dec 2024 15:26:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRXku-0008Rw-55; Sat, 28 Dec 2024 09:25:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRXks-0008NC-D9 for emacs-devel@gnu.org; Sat, 28 Dec 2024 09:25:26 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRXkr-0005sc-G1; Sat, 28 Dec 2024 09:25:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=qea7G8jXqjW73uiIq3XaZhG8l3EYWvJCua3+cstI+wM=; b=gkWE2vwcmeG2 eAcig5f+JMGd23bSbwOa0U51JwzK1Qa6KXr8Fv3HvanXpdAmgvDiecwgyc2o+nRrmm9f755xJJ3Lu pB54zvRpHHPuBDKysJde0oUXbUNItZZm9IrtGZ9ZoPW7uX8L4D5S4FU/bP2BlRrFLjz38giQ6WSOB nx++BecHjm986/3+CheXNH1vvRYjFHCTofHsLKIDhH+E7S/W05Hix3MLKMTW9FQeht4LKq63S8rH0 zj20sFlX24ePB4xv5W+XLe+1h2oJ3P4NZ3BOb4YVCk4YtNDVfBYBEPS02QLucZ18K/BwvesgdmdhM TH4NA9X1xyP/lwudyBOE0g==; In-Reply-To: <877c7jlxsu.fsf@gmail.com> (message from Helmut Eller on Sat, 28 Dec 2024 14:52:33 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327270 Archived-At: > From: Helmut Eller > Cc: pipcet@protonmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, > emacs-devel@gnu.org, acorallo@gnu.org > Date: Sat, 28 Dec 2024 14:52:33 +0100 > > On Sat, Dec 28 2024, Eli Zaretskii wrote: > > >> It seems that the statement > >> > >> block SIGPROF while MPS holds the lock > >> > >> is logically equivalent to > >> > >> deliver SIGPROF only while MPS does not hold the lock. > > > > Not necessarily. Blocking a signals delays its delivery until the > > time the signal is unblocked. By contrast, what you propose will be > > unable to profile code which caused MPS to take the lock. > > Hmm, I think I disagree. But I'm not sure of what sequence of events > you're thinking of. I'm thinking about a situation where SIGPROF was delivered while it was blocked. In that case, it will be re-delivered once we unblock it. By contrast, if we avoid delivering SIGPROF in the first place, it will never be delivered until the next time SIGPROF is due. So imagine a function FUNC that conses some Lisp object. This calls into MPS, which blocks SIGPROF, takes the arena lock, then does its thing, then releases the lock and unblocks SIGPROF. If SIGPROF happened while MPS was working with SIGPROF blocked, then the moment SIGPROF is unblocked, the SIGPROF handler in the main thread will be called, and will have the opportunity to see that we were executing FUNC. By contrast, if the profiler thread avoided delivering SIGPROF because it saw the arena locked, the next time the profiler thread decides to deliver SIGPROF, execution could have already left FUNC, and thus FUNC will not be in the profile. I hope I made myself more clear this time. > >> This variant might be bit easier to implement. The "while MPS does not > >> hold the lock" part can be implemented by claiming the lock in the > >> profiler thread like so: > >> > >> mps_arena_t arena = global_igc->arena; > >> ArenaEnter (arena); > >> ... deliver SIGPROF part goes here ... > >> ArenaLeave (arena); > > > > What happens if, when we call ArenaEnter, MPS already holds the arena > > lock? > > Since MPS holds the lock, it would run in a different thread. Yes, of course: we are talking about an implementation where the profiler thread is separate, so the above code, which AFAIU runs in the profiler thread, will be in a thread separate from the one where MPS runs. > So the profiler thread blocks until MPS releases the lock. > > ArenaEnter uses non-recursive locks. Hm... if ArenaEnter uses non-recursive locks, how come we get aborts if some code tries to lock the arena when it is already locked? IOW, how is this situation different from what we already saw several times in the crashes related to having SIGPROF delivered while MPS holds the arena lock? > > >> The "deliver SIGPROF" part goes like this: > >> > >> 1. The profiler thread calls pthread_kill (SIGPROF, ) and > >> then waits (on a pipe or whatever). > >> > >> 2. The SIGPROF handler gets called and immediately notifies the profiler > >> thread (without waiting for a reply). After that, it continues as > >> usual calling get_backtrace etc. > >> > >> 3. The profiler thread awakes and releases the lock. > > > > This leaves a small window between the time the SIGPROF handler writes > > to the pipe and the time the profiler thread calls ArenaLeave. During > > that window, the arena is locked, AFAIU, and we can still have > > recursive-lock situations, which cause an abort. Am I missing > > something? > > During that time window, the lock is held by the profiler thread. The > SIGPROF handler runs in the main thread. If the main thread tries to > claim the lock, it will block until the profiler thread releases it. See above: I thought that such a situation triggers crashes. I'm probably missing something. > >> Regarding deadlocks: the profiler thread holds the lock while it waits. > >> So MPS should not be able to stop the profiler thread there. > > > > Which means we don't register the profiler thread with MPS, right? > > I'm not sure. It may not be safe to call ArenaEnter in non-registered > threads. But if we do register the thread, then MPS _will_ stop it, no?