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: Some experience with the igc branch Date: Sun, 29 Dec 2024 08:15:24 +0200 Message-ID: <86pllbqakj.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <87cyhf8xw5.fsf@protonmail.com> <86y103zm4m.fsf@gnu.org> <8734ia79jq.fsf@protonmail.com> <86pllexwru.fsf@gnu.org> <87ldw15h6s.fsf@protonmail.com> <86a5chw20u.fsf@gnu.org> <871pxt5b8u.fsf@protonmail.com> <865xn3sn2e.fsf@gnu.org> <871pxrecy7.fsf@protonmail.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="28559"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 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 Sun Dec 29 07:16:26 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 1tRmbC-0007Kx-Go for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Dec 2024 07:16:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRmaM-0002ea-Ig; Sun, 29 Dec 2024 01:15:34 -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 1tRmaI-0002e3-8S for emacs-devel@gnu.org; Sun, 29 Dec 2024 01:15:31 -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 1tRmaG-0003en-1f; Sun, 29 Dec 2024 01:15:28 -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=qu2GoLeyT0VtKgjGUTaRZbTcKRp7AJXCQ6q5YeToyyM=; b=ch+HbhML3d/Ri+p2O1a0 o2taPemOY6X2AWGZmvPmB5vZv9pjD4QAzC4702zBb7AaqlbjhS9uxq5P6pVJKAXpn2VBJKgzmVn12 chvOO6EA4rePZ/CdZxzspDzH+6p7MaoyjZWtNpM6VxzBDB83ZiCBlXucuEYNcnQpLrgaYyDuGDdvJ +4VW+C1SaRnGjMTF64iFVYwtWIrJbqgZgyieG531Z6s7mnzmYkT9H4aBP5Jr73E9dzz6c+bMx7kQh Na+8lxZWGl9bi7EkMk++N5rRNwFEijrEYNFRZKNwKGRw/rgwbRODi9Uq7xxa1FHAYKYkKOv8wOwbJ qRyeiFn7Cfhlmg==; In-Reply-To: <871pxrecy7.fsf@protonmail.com> (message from Pip Cet on Sat, 28 Dec 2024 21:05:43 +0000) 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:327313 Archived-At: > Date: Sat, 28 Dec 2024 21:05:43 +0000 > From: Pip Cet > Cc: gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org > > "Eli Zaretskii" writes: > > > By > > contrast, under your proposal, MPS should be called from a separate > > thread. However, the way we currently process signals, the signals > > are delivered to the main thread. So we should install our own > > SIGSEGV handler which will run in the context of the main thread, and > > should somehow redirect the handling of this SIGSEGV to the MPS > > thread, right? > > Correct. > > > So now the main thread calls pthread_kill to deliver > > the SIGSEGV to the MPS thread, > > No, that wouldn't work. We need the signal handler to have access to > the siginfo_t data, and pthread_kill provides no way to include that > information. > > Instead, we call the SIGSEGV handler directly on the other thread, > passing in the same siginfo structure. How can we call the SIGSEGV handler directly from another thread? And how will that thread know it needs to call the handler in the first place? > (My original code simply accessed a byte at the fault address; however, > reading the byte isn't sufficient, and writing it risks exposing > inadmissible intermediate states to other threads, so now we call the > sa_sigaction function directly). > > > but what will the MPS thread do with that? > > Call the MPS SIGSEGV handler, which knows what to do based (currently) > only on the address. > > > how will it know which MPS function to call? > > The MPS SIGSEGV handler is obtained by calling sigaction. That's unreliable: it assumes that no one else calls sigaction after MPS, or changes the chain of handlers in some other way. Also, on MS-Windows MPS doesn't use a signal handler (because there are no signals on Windows, really). It uses an exception handler, and I don't think there's a documented method of getting at the handler after installing it. So we'd probably need to call the MPS function directly, leveraging our knowledge of the MPS internals. That's assuming we can call the exception handler outside of the context of a real exception, which I'm not at all sure we can. In sum, this part of your idea, of simulating a segfault/exception due to access to protected memory, sounds to me to be quite fragile and unreliable. > >> >> 4. we don't trigger memory barriers > >> > > >> > Same question here. > >> > >> I meant all four conditions are necessary, not that any one of thew > >> mould be sufficient. > >> > >> GC can happen if another thread triggers a memory barrier OR another > >> thread allocates OR we hit a memory barrier OR we allocate. The > >> question is whether it is ever useful to assume that GC can happen ONLY > >> in these four cases. > > > > GC can also happen when Emacs is idle, and at that time there's no > > allocations. > > If you want to spell it out, sure, but there's no way for the main > thread to become idle without potentially allocating memory, so this > fifth condition is redundant. I don't understand why the assertion "there's no way for the main thread to become idle without potentially allocating memory" is true. Emacs becomes idle because there are no input events to process, and that has nothing to do with allocating memory. The GC we trigger when Emacs is idle might find that there's no garbage to collect, but AFAIU it will nevertheless take the arena lock. But if this is not relevant to those conditions (which I frankly don't understand why they are needed), then we could stop arguing about that aspect.