From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Mon, 23 Dec 2024 23:37:13 +0000 Message-ID: <87ldw6as5f.fsf@protonmail.com> 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> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35536"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 24 04:22:10 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 1tPvUo-00095H-PN for ged-emacs-devel@m.gmane-mx.org; Tue, 24 Dec 2024 04:22:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPvTR-0003sf-K0; Mon, 23 Dec 2024 22:20:45 -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 1tPrzH-0003FE-Hi for emacs-devel@gnu.org; Mon, 23 Dec 2024 18:37:23 -0500 Original-Received: from mail-10630.protonmail.ch ([79.135.106.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPrzF-0007W4-8J for emacs-devel@gnu.org; Mon, 23 Dec 2024 18:37:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1734997038; x=1735256238; bh=muHIH7p3L/Sp5XAOpQMjUBkNshnbMFmHtfLMIC0LrdA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=fxjgOiwtOnNnHCgfNxGNxCV3ADp3461DjqWLUnEQviMQNZuPCacnCxT2sI4MX9og8 Ykijlz6AnAOKY/RC++BqEBOBOKxIQ1PWmin+whHg5VldyCraLTmPWHC4gFVWwwfPcP 8YuH0UGA+IS6HSyphgNF3kXdbkl1kpjTlYqE+pWbljlbm5TuNVDb3Z/zj2BuZV/SXb OOSUiRSbXdQdSCFqo19zlKgzT7y7LKpXW+hpVJ/m1qeAlo/WiF7jABFsmtIYptgT6h GIdTFHn4thIUCZ+SJbFttqaTsF1OLeO9hjVYncz02+1hdVqbdq0g9UEyUUmaYJv/Qa BqOfdp1FT8MEg== In-Reply-To: <864j2u442i.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: d95d1f0547ab33f5db1fe089d71b540734bf867c Received-SPF: pass client-ip=79.135.106.30; envelope-from=pipcet@protonmail.com; helo=mail-10630.protonmail.ch X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 23 Dec 2024 22:20:43 -0500 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:326950 Archived-At: "Eli Zaretskii" writes: >> From: Gerd M=C3=B6llmann >> Cc: Eli Zaretskii , ofv@wanadoo.es, emacs-devel@gnu.org, >> eller.helmut@gmail.com, acorallo@gnu.org >> Date: Mon, 23 Dec 2024 18:44:42 +0100 >> >> BTW, do you know which signal handlers use Lisp, i.e. allocate Lisp >> objects or access some? All? Or, would it be realistic to rewrite signal >> handlers to not do that? I think there are several questions hiding behind the first question mark: 1. which signal handlers want to read Lisp data 2. which signal handlers want to write Lisp data 3. which signal handlers want to allocate Lisp objects temporarily, while guaranteeing no references to those objects survive when the signal handler returns. 4. which signal handlers want to allocate Lisp objects permanently, storing references to the new objects in "old" data 4a. ... and are willing to call a special transformation function to do so 4b. ... and want to do so implicitly, expecting memory manipulation to "just work". 1: definitely works 2: should work, but may hit a write barrier 3: could be made to work if there's interest 4a: if we must 4b: see the other thread. If we have both make_object_writable (formerly CHECK_IMPURE) and commit_object_changes functions and call them consistently, it might be possible to find a way. > SIGPROF does (it's the basis for our Lisp profiler). That's 1, 2, but not 3 or 4, right? > SIGCHLD doesn't run Lisp (I think), but it examines objects and data > structures of the Lisp machine (those related to child processes). Just 1, then? >> One thing I've seen done elsewhere is to publish a message to a message >> board so that it can be handled outside of the signal handler. Something >> like that, you know what I mean. > > This is tricky for the profiler, because you want to sample the > function in which you are right there and then, not some time later. But would it be so bad to use a copy of the specpdl stack, placed in a prepared area which is a GC root so we'd guarantee survival (but not immutability; I don't think that matters in practice) of entries? memcpy is safe to call from a signal handler, and then we could do all of the processing safely. (My preference would be to make the specpdl stack an ambiguous root while the profiler is in use: that way, we'd get usable backtraces even if the SIGPROF happened during GC, which is probably more useful than merely saying that we were in GC). Pip