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: Gap buffer problem? Date: Wed, 11 Dec 2024 17:41:29 +0000 Message-ID: <87v7vqjexy.fsf@protonmail.com> References: <87bjximwnj.fsf@protonmail.com> <87ttbal9qx.fsf@protonmail.com> <877c86l1aj.fsf@protonmail.com> <86o71i2m2e.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="27360"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , emacs-devel@gnu.org, ofv@wanadoo.es To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 11 19:52:01 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 1tLRoW-0006wk-RI for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Dec 2024 19:52:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLRnj-0004NH-8t; Wed, 11 Dec 2024 13:51:11 -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 1tLQiQ-00027t-6g for emacs-devel@gnu.org; Wed, 11 Dec 2024 12:41:38 -0500 Original-Received: from mail-40133.protonmail.ch ([185.70.40.133]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLQiN-0002jn-Jj for emacs-devel@gnu.org; Wed, 11 Dec 2024 12:41:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733938892; x=1734198092; bh=kFomNynKpGEZhLSRHmoox2+wW8kTav9+Aaa3lh/N8J8=; 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=peeV6Saoa/4Jjpa3TJ+vAgWcBTkIb3x1vUewkd73gAuQCkOsZeWiXDa6sn3CQSSTi 7oR5H9YJUiny2XTA6/l4gDpyNYjeWdLfHBzt5VkoqnNgsh1wj4lqGlJdgrbJoTOy+6 YW2lP67rPIM+VqjZlz/NWBsE/wDX9VXIRiIWOHp6aYQskKcgDxW1+NV6kHx1GlMCQv uCAkcth0iSaYFG5V/WYN7ffZgMjvSwKeWtlKIllWHPTUIbScNYpzyxcub9JuowG6iZ +KpP4ittH9XhiTNJAqCWo6FO2bGVJ6bInMsyzW2gXbWIxgIv8I/5y7xiDLai6euFKx YbWWUCh8Axfbg== In-Reply-To: <86o71i2m2e.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: ff4858e3e3e54b63bfbb3b271b718237e5ed63c0 Received-SPF: pass client-ip=185.70.40.133; envelope-from=pipcet@protonmail.com; helo=mail-40133.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 11 Dec 2024 13:51:08 -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:326375 Archived-At: "Eli Zaretskii" writes: >> From: Gerd M=C3=B6llmann >> Cc: "Pip Cet via \"Emacs development discussions.\"" , >> =C3=93scar Fuentes >> Date: Wed, 11 Dec 2024 16:33:18 +0100 >> >> Pip Cet writes: >> >> > This may be a very stupid idea, but why not use a separate process? >> >> Not stupid at all. I thought about something similar in a different >> context, namely if one could decouple the GUI part of Emacs from the >> rest. > > If it can be done by two processes, it can also be done by two threads > in the same process. Right? AFAIU: No, not right. I may have misunderstood, but if the idea is to preserve a consistent state of all Lisp data and buffer text for redisplay to use, the easiest way to ensure that consistency is fork(). The other ways, such as copying all heap objects that might be used by redisplay (and adjusting all internal pointers in such heap objects to point to the copy rather than the original data), probably will end up either being a lot slower or being very specific to the system we're running on. I know that implementing fork() on Windows is very slow, and I don't know about a comparable snapshotting mechanism for Windows. To be honest, though, I'm a bit disappointed that GNU/Linux appears to make fork() take significant time that is proportional to the size of the mapped address space, even if it's never COW-faulted in. I'm pretty sure that could be avoided (and I hope the Linux kernel avoids doing it for swapped-out memory, not that anyone still does that). Concurrent access to Lisp data from several threads requires a locking mechanism (fine-grained or coarse) for all such data, and possibly requires rewriting addresses, which means no "ambiguous" references whatsoever. That's a lot harder than using MPS, which generously allows for ambiguous references. It's possible we could have gotten away with concurrent access by the redisplay machinery if we inhibited GC while the redisplay thread was busy inspecting our data, but inhibiting MPS GC is a lot harder and shouldn't be done for ordinary operations. Oh, and of course mmap() breaks fork()'s snapshotting magic. The reason I said this depends on a new GC is a bit subtle, by the way: the old GC does best if we sacrifice a lot of memory and only run it rarely, which we can usually get away with because RAM is cheap. With a fork()-based approach, memory usage comes with a performance penalty for every fork(), so we need to reduce both memory usage and GC time, which we can't do with non-incremental GC. The last reason it's difficult is that MPS isn't optimized for multi-thread settings: in an ideal world, "scanning" a memory area would use a secondary mapping of the memory, known only to the scanning code, so other threads could continue running while an area is being scanned. With MPS, there is only one mapping, so we need to stop all other threads while one thread un-mprotect()s a memory area to scan it. Unless MPS breaks POSIX threads in some spectacular way, fork() should still work, though. Pip