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 19:54:07 +0000 Message-ID: <87ldwmj8sw.fsf@protonmail.com> References: <87ttbal9qx.fsf@protonmail.com> <877c86l1aj.fsf@protonmail.com> <86o71i2m2e.fsf@gnu.org> <87v7vqjexy.fsf@protonmail.com> <86cyhy2g97.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="16626"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 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 21:08:38 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 1tLT0f-0004CI-Rc for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Dec 2024 21:08:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLSzv-0005qH-Ey; Wed, 11 Dec 2024 15:07:51 -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 1tLSmn-0004EU-3Q for emacs-devel@gnu.org; Wed, 11 Dec 2024 14:54:17 -0500 Original-Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLSmk-00010y-VD for emacs-devel@gnu.org; Wed, 11 Dec 2024 14:54:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733946852; x=1734206052; bh=xe5b5SKT3yJB/V8j8RnZn14OyK4c7AadKBByDolYFZI=; 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=CanDQ3AN4MIU9Q52PbTLCdDV2giZMixd9YKINavE5bPLwmOjsqWbopLkAjfLIlmzb 4KlNWVgSM+LUi8iDGcJEsI/g6cPd/3qmARWUu/RbGiDagYSr2DWrQ1w6RJz+IZzrOX PrAm74fXT+aFxoGooCtuNmMg89cVC2fUSYkZFzzekAh61EDh++wm72nmrmHdWE3HkI MHIfPoFmbxRQzFFOg/ath8R3Hw95dAkpMa6paPgBQwoR0wNcO58L8qADutZlafgP75 t1KRiK/zbiNcRXYt98SJ0enP0jbMon+fG8kFxnh146aMrQt9KJGduFf6g+GEpZhuYN MaJuymtiGTLHQ== In-Reply-To: <86cyhy2g97.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b822d5060792ba414df33d724ccb60b8d89e1580 Received-SPF: pass client-ip=185.70.40.134; envelope-from=pipcet@protonmail.com; helo=mail-40134.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 15:07:50 -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:326380 Archived-At: "Eli Zaretskii" writes: >> Date: Wed, 11 Dec 2024 17:41:29 +0000 >> From: Pip Cet >> Cc: Gerd M=C3=B6llmann , emacs-devel@gnu.org, = ofv@wanadoo.es >> >> "Eli Zaretskii" writes: >> >> > 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. > > How do you do the same in a forked process? The glyph matrices are > not allocated once, they are reallocated constantly. Are you going to > fork each time? Not necessarily "each time" (meaning once per frame/keystroke), but quite frequently, yes. > And if you are, how is it different from copying > stuff lazily within the same process, exactly like the OS does with > forked processes? It is very different indeed: Copying within a process involves changing the (virtual) addresses that the copied data is at (unless you use an architecture-specific implementation of TLS). The beauty of fork() is that the virtual addresses stay the same, so we don't need to adjust any pointers, which we cannot do because there are ambiguous references to Lisp data. IOW, no, you can't lazily create two copies of Lisp data in the same process. You have to do so eagerly, adjusting any and all pointers (and only those) in the Lisp data before the new data is read for the first time (because what you read might be a pointer, and then it needs to be adjusted). With fork(), you only have to make the copy when the data is being written to, by either process. (Of course you can just access all memory through some sort of API that translates addresses for you, but that would effectively mean we'd be running Emacs on a virtual machine and simulate fork() on it). > Anyway, the fact that redisplay calls Lisp and Lisp calls back into > redisplay all but kills this idea. Gerd's document has also other > gotchas. We didn't just give up easily back when we discussed that. I don't see why the redisplay process would not be able to call Lisp; it's a full Emacs process (with a single thread), except it doesn't have an FD or socket for the window system, and has an extra pipe to communicate with the parent process instead. It's true that the side effects of the called Lisp code won't be visible to the next redisplay process, but such side effects are perilous anyway, and avoiding them would seem to me to be a feature, not a bug. However, if such side effects are desired, we can use IPC to execute Lisp in the main process (some effort) or simply send a "this redisplay needs to happen synchronously" message to the main process, which would kill the current redisplay process and perform a synchronous redisplay (as not all operating systems support fork() reliably, we'll have to retain the ability to redisplay synchronously, either way). But, to be perfectly honest, I'm not sure redisplay is slowing me down the way traditional GC is. Pip