From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Tue, 24 Dec 2024 05:03:36 +0100 Message-ID: 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> <87ldw6as5f.fsf@protonmail.com> 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="14885"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 24 05:04: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 1tPw9z-0003jj-BH for ged-emacs-devel@m.gmane-mx.org; Tue, 24 Dec 2024 05:04:43 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPw95-0004ks-BF; Mon, 23 Dec 2024 23:03:47 -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 1tPw92-0004kQ-ST for emacs-devel@gnu.org; Mon, 23 Dec 2024 23:03:44 -0500 Original-Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tPw91-0001MG-82; Mon, 23 Dec 2024 23:03:44 -0500 Original-Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5d34030ebb2so1798420a12.1; Mon, 23 Dec 2024 20:03:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735013019; x=1735617819; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=HpHjp+lHp6ZLNJzWc+dWsXP3POG5oE7PAj6Y1VMNFiw=; b=JW1xwqazG4fCZ+4Jd8x5MJej1cND3ic8CYqy8RcaYBtpuWEDqJ0gGBf/syKiJd3WLR BGDlwXTHOcrR03PqzqB7CgSa9tISpGWF+ajs5lbPbW/pEpXsDsBfqOnLuaFHm/v2aifj MEBEPe8xABPegZpdkge5MhadTqZPMgjXmCHUaeTTqGU4m9iJZvT+k4gkPxiRT1M8k+uS Yae0nFcWBTpAxx4hwG+vtACRgiIbN3fGy6/mITokSeiK7Zg7A4Vy0jEUqd0q3wS9u/mt SxzhPUDCDyzNMAz9iuYxMt6ZU+0NNphE4foGRW0BALHQM8+VUJdamu1665lkoPGv8tJw 8/bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735013019; x=1735617819; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=HpHjp+lHp6ZLNJzWc+dWsXP3POG5oE7PAj6Y1VMNFiw=; b=ajl+9njwRElr3YrM++KwLgqcqWm51mMUlrIhXWBedV3j8tyXprTF7X4d06jiPFOGdq O0eZOqgNIo8KmXUsEUtu6D9qLak6DOFNqCySKoAPWib2EFFKPy4WU2xR/47sMG7Cjq5z MY6rSpk5ZCz+fYzCOyjxJVJ0lcdnVSaKwYdZLjpL4V9jYeFExfNKq9i6q099Sv9hnL8s MXTRiQLt2qbptiXs0gk6tM4pZrYPWzf+JeZ41/80S/MvhJHB9/UffQKE7cYS+yfwel/k aHm4SYCqwHtPAs+9+Z8VBvRA0gwt1JxK0TNjIuwOHX1huvdio0sqnUOo08G65DQD8nke uMvQ== X-Forwarded-Encrypted: i=1; AJvYcCVP6cljj+5nB2I4T0WMkDssGdaDnrIue2DDddgUOZLr41OPIYjmiMuPIC1iJXZ3hNNdwNZL0NjjtQ==@gnu.org, AJvYcCXJaKZTzgR+BWu5wZwvaL8DZxJDcAKjZ28eLiPOYg4SZnWrLDPALkHwGae37Las1cbdTvK1qhZpyDesjb4=@gnu.org X-Gm-Message-State: AOJu0YxXUvdri7wGSAVf9p3pjx2PWD8YS/g0ZsvdyAepJM96fbcMV9WT v6Rsb0efaTMX3nMrm7ZArSuZMsDOvtYDmxSZuVMnkhQPG+1p/e9dbPeP5w== X-Gm-Gg: ASbGnctYEBoLHByskhU08m6uOceFeqXS8G+zE3iVWTFxMr05pbagYx1r/fs+xWWJ2cz nT3wm3wE3tmmYga/X4bZNYZcBQ6+PrFCvcoSXChTtDruqsc0s6jVxkwN2lUJyzsqpAcw5gJXx+R al4wxySDKUBER+oq4MeqjENCL46aLA7rmy/PF3za2phRCujivcNJT9hwiOw6jGcU8T5vyiuDA4X g7BrE/HBDOLT5E8fImbVlrTaIHxeMFlQcbEQ4tsQgIKbJhf+KlR6pU9FL2cE4C2JCBF7hHPpgyz JyBUPzBMH45duYejBz7aaBcuHqIq04OqeVKXr399R+alAxWuPqM1/6msE6uLLixrdg== X-Google-Smtp-Source: AGHT+IElnj+uN08uOE4AVvg5Bbg6AHKgCYfUXNtTkj9jVyZ6v3t2/sorHYkfWb/SXbRRC2udkiip6A== X-Received: by 2002:a17:907:3e90:b0:aa6:abb2:be12 with SMTP id a640c23a62f3a-aac3354ff4dmr1109205766b.37.1735013018991; Mon, 23 Dec 2024 20:03:38 -0800 (PST) Original-Received: from pro2 (p200300e0b7326d00f9ed2197837c3ebd.dip0.t-ipconnect.de. [2003:e0:b732:6d00:f9ed:2197:837c:3ebd]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0f06dc7esm597914566b.193.2024.12.23.20.03.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Dec 2024 20:03:37 -0800 (PST) In-Reply-To: <87ldw6as5f.fsf@protonmail.com> (Pip Cet's message of "Mon, 23 Dec 2024 23:37:13 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::52c; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x52c.google.com 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:326953 Archived-At: Pip Cet writes: > "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". New day, new beliefs :-). Today, when I read my question again, I'd actually be surprised if a signal handler could allocate Lisp objects because I wouldn't be able to explain how that works with alloc.c which isn't reentrant. Not even Fcons is reentrant when I look at it now. Correct, or am I overlooking something? Could others please check? If it's right, things get a lot easier. Maybe allocation of Lisp objects on the stack remains as some sort of problem (AUTO_CONS etc)? I don't see how though, ATM. > 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 I'd prefer to send messages from handle_profiler_signal. Or something equivalent to sending messages. Please see my other mail where I looked at that function. Implementing such a message board is of course not easy. But I think it would be easy to understand how things work once one has something like that. And if I'm right with what I wrote above about allocation (and I think I am), we also don't need provisions for allocating Lisp objects from signal handlers, which would be a great simplification.