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: Sun, 29 Dec 2024 22:08:47 +0200 Message-ID: <86msgep7zk.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> <87a5cnfj8t.fsf@protonmail.com> <86seqe4j4f.fsf@gnu.org> <87ttaucub8.fsf@protonmail.com> <87pllicrpi.fsf@protonmail.com> <864j2u442i.fsf@gnu.org> <87a5ch5z1b.fsf@gmail.com> <86y101wlsr.fsf@gnu.org> <87msgeb9y6.fsf@gmail.com> <86ttampax7.fsf@gnu.org> <87ed1qb7ws.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31472"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, pipcet@protonmail.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 Sun Dec 29 21:09:43 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 1tRzba-00081E-Bn for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Dec 2024 21:09:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRzbA-0006Mk-L3; Sun, 29 Dec 2024 15:09:16 -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 1tRzb8-0006Ma-84 for emacs-devel@gnu.org; Sun, 29 Dec 2024 15:09:14 -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 1tRzb7-0006UL-A9; Sun, 29 Dec 2024 15:09:13 -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=4NF1slpb2IwTTnsVQQ9e9pmedAMXw5soxeR8/iwRNj4=; b=YjuB6ZNwsKe4 c4JZQszu9KL51Kqpmd9NZTAoHPyvluLmP5QWJWHsehZ5nL66XhSoVxRpW8JNDJXuhW/0dr9GHLKNc N1NMPOq38K1RXmweBLo4lqYVErwY3uUMgXMPEbjdCJxOjEJXkzqq/6KtxuGachoBEvlv+jkSnVuIC DQ+ORGnT5ISF8broXkVZati6pqHgnr5fON1Tt0xnwc2FcAuwWeBIhh4cp0ZFJsk7+RgZVNNY7bzpt zpF1nK2SNS+eG6oCcC4ucwObcfwk70i8w2Q/4SWzXecDKNwNKNtFayqSYSUdC2D/qXruR2YGBG9jm 2Lbaj0q/bqanwHq7/ELzqg==; In-Reply-To: <87ed1qb7ws.fsf@gmail.com> (message from Helmut Eller on Sun, 29 Dec 2024 20:34:11 +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:327368 Archived-At: > From: Helmut Eller > Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, ofv@wanadoo.es, > emacs-devel@gnu.org, acorallo@gnu.org > Date: Sun, 29 Dec 2024 20:34:11 +0100 > > On Sun, Dec 29 2024, Eli Zaretskii wrote: > > >> Here another observation: Let's assume that we can emulate SuspendThread > >> and ResumeThread on POSIX and MacOS (much like MPS does it). In the > >> profiler thread we can then simply do: > >> > >> SuspendThread () > >> get_backtrace () > >> ResumeThread () > >> > >> without invoking any SIGPROF handler or the need for > >> ArenaEnter/ArenaLeave. > > > > Yes, we can. But that means changing what the SIGPROF handler does > > will have no effect, which is bad for maintenance. By contrast, the > > current MS-Windows implementation does basically the same, but it > > calls the handler, not its body. > > > > Also, I don't quite see why you thing calling get_backtrace directly > > will have any effect on the need to lock the arena. I'm probably > > missing something. > > Ok. The arena lock is a problem. Is that also a problem for the Windows > implementation? How does it avoid deadlocks when the thread holds the > arena lock? You mean, when the SIGPROF handler is called by the thread which simulates the SIGPROF signal? The handler is called in the context of the signaling thread, not in the context of the (suspended) Lisp thread. > >> The only complication seems to be, that we must avoid deadlocks when MPS > >> tries to suspend a thread is already suspended by our emulation. > > > > If MPS always runs from the main thread, it doesn't (and cannot) > > suspend the thread. Or maybe I misunderstand which thread do you mean > > here? > > I may interpret "MPS runs in a thread" differently than you do. Maybe I > should say a "thread is inside MPS" whenever a thread holds the arena > lock. With this meaning, every thread can be inside MPS. Suspending a suspended thread on Windows doesn't cause any problems (unless you do that more than 127 times without resuming the thread), it just increments the thread's suspend count. To resume, you need to call ResumeThread that many times. Does that answer your question?