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: Fri, 27 Dec 2024 10:51:48 +0200 Message-ID: <86y101wlsr.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> 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="38902"; 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 Fri Dec 27 09:52:52 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 1tR65U-0009yL-51 for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Dec 2024 09:52:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tR64q-0006cm-SX; Fri, 27 Dec 2024 03:52:13 -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 1tR64n-0006cE-2D for emacs-devel@gnu.org; Fri, 27 Dec 2024 03:52:09 -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 1tR64m-0007KK-3X; Fri, 27 Dec 2024 03:52:08 -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=nGBTrrlxv4WhU5tMP2+6x557trkvxUFQRnPAH3eepzw=; b=qvJCco6MqEB34FdAz7mW gqKPfj4qpfV3m4UtZlCud4z/xlBK/XPSyf5mkbe+Pj3ACYO1pyDMiVzYAiBx5eraPW3KWc5FY6amA QetuVL2iNWUJenveNqlSe7qaXj6qDtgfDmvi4aAh12rFEspy29NPlarkQIL/9tn7Cu8hxDpnCVugP gdYZw6IpqYuuqr5OkBXWZ6D6NCowHTx3HvMpg29D8GC+O+Gu6aKEoA94g4X/NpIO8WSC3qUhPklpN u02lXv2+s+uhwvKS4mpc1Ll6dEWEaqdjb92/GEcsV6XQR0qgSCCgiDFEWEtH9j0q4z6hevcLjcoGj 5BIUmKyV9hvBqg==; In-Reply-To: <87a5ch5z1b.fsf@gmail.com> (message from Helmut Eller on Fri, 27 Dec 2024 09:08:00 +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:327178 Archived-At: > From: Helmut Eller > Cc: Eli Zaretskii , pipcet@protonmail.com, ofv@wanadoo.es, > emacs-devel@gnu.org, acorallo@gnu.org > Date: Fri, 27 Dec 2024 09:08:00 +0100 > > On Tue, Dec 24 2024, Gerd Möllmann wrote: > > >> I've looked at SIGPROF. From an admittedly brief look at this, I'd > >> summarize my results as: > >> > >> - The important part is get_backtrace. The rest could be done elsewhere > >> by posting that to a message board, or whatever the mechanism is at > >> the end. > > I have an idea how to make a safer profiler. First, remember that MPS > will stop mutator threads to protect its own consistency. Can you spell out what are "mutator threads" in this context, so we all are on the same page? > What happens if we make the profiler its own thread? MPS will stop > the profiler like normal mutator threads. This is useful and is as > it should be. AFAIU, it means the profiler will not be able to account for GC, but let's put this aside for a moment. > The problem now is how the profiler thread can do what get_backtrace > does. We can use a protocol between the profiler thread and the main > thread that goes like this: > > 1. The profiler periodically sends a signal, say SIGPROF, to the main > thread. > > 2. In the signal handler for SIGPROF, the main thread synchronizes > itself with the profiler by communicating over a pipe (like the Unix > fathers did it). It sends some token to the profiler and waits. > > 3. The profiler receives the token and can now access the virtual > machine state because the main thread waits. The profiler now does > what get_backtrace does. After logging the stack snapshot, the > profiler sends the token back to the main thread > > 4. The main thread receives the token, returns from the signal handler, > and continues execution. You are basically describing the way SIGPROF emulation is implemented on Windows (see w32proc.c for the details). But I don't understand why you need that pipe: doesn't pthreads allow one thread to stop the other? If so, just make the "profiler thread" stop the main thread instead of your step 2, and resume the main thread instead of your step 4. Am I missing something? > Note that the signal handler only communicates over the pipe and doesn't > read or write any memory that could mess up MPS. The profiler thread > doesn't run any signal handlers (other than those that MPS may use > behind the scenes). You basically emulate blocking of SIGPROF by relying on MPS to stop the profiler thread when it cannot allow access to memory that could mess up MPS, is that right? > Another observation: MPS sends SIGXFSZ and SIGXCPU to stop and resume > threads. We could intercept those signals and block SIGPROF while the > thread is stopped. Obviously a hack, but could still be useful. Do these signals get delivered to the main thread as well? Or only to mutator threads?