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 12:50:15 +0200 Message-ID: <86bjwwulnc.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22827"; 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 11:51:09 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 1tRUPU-0005ll-Ns for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Dec 2024 11:51:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRUOl-000239-I7; Sat, 28 Dec 2024 05:50:23 -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 1tRUOh-00022Z-B1 for emacs-devel@gnu.org; Sat, 28 Dec 2024 05:50:19 -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 1tRUOg-0000Yf-Ms; Sat, 28 Dec 2024 05:50:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=bKCNAuPULgywJLbWoqqRmZC61SuR+Mg2v5JBi3JBIH8=; b=TM8HJiJgasxghzSWCQ+h BEk0C87YSwq0T9GZ/UAeX1vA3O1gIcdef8ZQOU6ywMH8cb+49eT1NAr9Q+R0oKtGcPj8dSYte1aHi 4Ot3La4tzwOKTDJS6ih0pMJkQcbn4xR/YbFJt91sXCTUfs/1XlsMiEaGDlJXZsP9a7nop9ccB8ric 80nzxW1+QNkN3F8O3Xsxadaq3poBavQdMbeYWFnse5S00qkv8gFLknpa4kLmEDIKIcaRZVJlkCiL8 9Kym1NbVE7olVSnHKL0S6/u8bjvOuEnwKuqG1p1t0yvHPh8vQjf58VJYm1jCTn+B+1iqCZi5HRgtr 7euc2aOGt2TORg==; In-Reply-To: <875xn46s6z.fsf@gmail.com> (message from Helmut Eller on Sat, 28 Dec 2024 11:02:44 +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:327250 Archived-At: > From: Helmut Eller > Cc: Gerd Möllmann , Eli > Zaretskii , > ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org > Date: Sat, 28 Dec 2024 11:02:44 +0100 > > On Fri, Dec 27 2024, Helmut Eller wrote: > > > Pip Cet via wrote: > >> ...forever, if the profiler thread has been suspended at this point. > > > > Hmm. Indeed. So back to the drawing board. > > 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. > 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? > The functions ArenaEnter and ArenaLeave are not part of the public API > but they are external symbols, so the linker can find them. We should ask the MPS folks what they think about using non-public API. > 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? > 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?