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 14:53:22 +0000 Message-ID: <877c86l1aj.fsf@protonmail.com> References: <86wmg7bso1.fsf@gnu.org> <87cyhzmzbp.fsf@telefonica.net> <87bjximwnj.fsf@protonmail.com> <87ttbal9qx.fsf@protonmail.com> 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="11631"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Pip Cet via \"Emacs development discussions.\"" , =?utf-8?Q?=C3=93scar_Fuentes?= To: =?utf-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 11 16:48:20 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 1tLOwk-0002qn-8p for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Dec 2024 16:48:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLOvh-0003Mf-6Q; Wed, 11 Dec 2024 10:47: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 1tLO5x-0004aI-BY for emacs-devel@gnu.org; Wed, 11 Dec 2024 09:53:47 -0500 Original-Received: from mail-10631.protonmail.ch ([79.135.106.31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLO5t-0004xb-Ay for emacs-devel@gnu.org; Wed, 11 Dec 2024 09:53:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733928807; x=1734188007; bh=NANhY92CsBTxBfYd5OAZijU/378nSKL6j8pWhv9vqvs=; 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=ac1bP9jFX+S76orSFoAxH0RZxkY8bql0GMo+fmn5Adb73QVJx8qMaZLGS0GHxS9Eu eCjP5ehj94XcmSfFTO5g9IS2gMUMs0XaWqQbVL9u0/tdO1OK6sxliyUAiYyJjtwx7a oA7ru4gx9aONai+fn9j8hEtR5xiP6jLnqOw5zFHxpK2OA6R7l5HCk8tKCEjuR6ooIx 8PIdoMzLw5Fu5dNVOvDrF91iGg8yUSolKePrz4cLY8KlJ3vsVQYf777C97muLeum4c OLbyfd4AI09b2my3F9JEyKcZWy9Obx/RmorjgBAW0OApZ+mlxJYIzcHidWffkR3RJw QU5Zqqinw0OBA== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 3ff5f9c2d95f954e20caf4f2de296a5250e24a99 Received-SPF: pass client-ip=79.135.106.31; envelope-from=pipcet@protonmail.com; helo=mail-10631.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_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=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 11 Dec 2024 10:47:09 -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:326363 Archived-At: Gerd M=C3=B6llmann writes: > Pip Cet writes: > >> Gerd M=C3=B6llmann writes: >> >>> Pip Cet writes: >>>> if we ever replace the gap buffer code, we should make sure its >>>> replacement actually handles buffer text and text properties/intervals >>>> in an integrated manner, rather than storing just buffer text). >>>> >>>> Pip >>> >>> And if I may add a wish to the future author: Make whatever you use >>> persistent data structures, so that one could think of letting redispla= y >>> run concurrently. Really! :-) >> >> You won't be surprised to hear I've been playing with some code, > > Indeed, I was just thinking to myself "I knew it" :-). > Two thumbs up! > >> so could I ask you to expand on this point? What precisely does >> redisplay require? Full snapshotting or would it be sufficient to have >> fine-grained locking? > > Maybe it's helpful when I tell something about the background. Some time > last year I asked myself if I could make Emacs more than one of my > plenty of CPU cores without solving the multi-threaded Elisp problem. > And the idea was that I could do that, possibly, by letting redisplay > happen in another thread. This may be a very stupid idea, but why not use a separate process? fork() is fast on GNU/Linux, and I suspect on macOS too, and the redisplay child would receive a consistent snapshot of the data to inspect and/or modify while coming up with the redisplay instructions, which it would then send back via a pipe or shared memory to be executed in the main process. I suggested doing something similar for GC (the GC child would perform a full GC and send back the Lisp_Objects which are definitely unreachable via a pipe. No, I never figured out how to make that work for weak hash tables which may resurrect references, I just made all hash tables strong...), and in that case the pipe seemed sufficient for the amount of data that was transferred, but I'm not sure how compact (or otherwise) serialized redisplay "instructions" would be. One issue I see is that fork() does a lot of housekeeping work in addition to marking the child's memory as a COW copy of the parent's memory at the time of the fork(). ISTR you can split that process on GNU/Linux (probably not Android), so you'd already have a prepared thread/LWP which wouldn't need to "start up" when you un-share the memory, but I can't find the relevant manpage right now. However, I have no real idea just how bad the fork() latency would be (as you point out, most people have more CPU cores than they can use, so I don't consider the approximate doubling of CPU usage a problem). This would deal very nicely with fontification code attempting to modify data it shouldn't, by ignoring such modifications. It would also deal with catastrophic failure in the redisplay code, as it's insulated in a separate process and we could just print a nice message in the main process rather than crashing all of Emacs. I'm emphatically not suggesting letting the redisplay child actually communicate with the X server or equivalent. That would be much more difficult. In fact, I think a good way to test this approach would be to use the tty code, since there's already a standard serialization of redisplay instructions for tty displays: VT100 escape sequences. > I later realized while thinking about the details, that this undertaking > is an order of magnitude too large for me. Everything taking more than a > few months is. And, in addition, I wouldn't want to do data structures > in C anyway. I think the VT100 case could be done as a weekend project (those always end up taking several weeks for me...), but I'm not sure it's worth it as VT100 redisplay isn't the common use case, and the performance problems are more visible on GUI terminals. And, like pretty much all Emacs ideas, this depends on having a better GC. (However, I've just experimented with an 8 GB process forking, and it's much slower than I'd hoped for - about 70 ms. I wouldn't be surprised if most of that cost is setting up page tables for the ridiculously small 4KB page size x86 uses, so it may work a lot better for AArch64 systems such as yours). Pip