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: Gap buffer problem? Date: Wed, 11 Dec 2024 21:04:20 +0200 Message-ID: <86cyhy2g97.fsf@gnu.org> References: <87bjximwnj.fsf@protonmail.com> <87ttbal9qx.fsf@protonmail.com> <877c86l1aj.fsf@protonmail.com> <86o71i2m2e.fsf@gnu.org> <87v7vqjexy.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="8287"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org, ofv@wanadoo.es To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 11 20:05:28 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 1tLS1X-0001tw-NF for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Dec 2024 20:05:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLS0f-0001Zr-9W; Wed, 11 Dec 2024 14:04:33 -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 1tLS0d-0001Ye-7p for emacs-devel@gnu.org; Wed, 11 Dec 2024 14:04: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 1tLS0c-0003oD-Fo; Wed, 11 Dec 2024 14:04:30 -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=uFk9oF+gd8wi9UIzw4fpFn8Q4st+BLjxwlQpVXCYjLk=; b=bN6LjW7ncJzb8qoJnPfK 6Z/MnyEZCNYtf4GdosWrjGWNxF5PX9BCLFEvr+twfvKaROa0Vm80JFiFvo+AEpMSUplOAh8a8jYd9 1VCvCsdIvyCLWDwahjP82HOcloia+z0CcKE/6+A6ztodbo/O0u/mYPcBieciJ4n7NHpb4MHzeJASt gWa3RZz3YRBFHF+SkpKRbtWZCQxKPhPgDWyD0B00389euVYmNC4J9s9NZ+CI15m8YxYD4N9s49IYW 2FX+gkfBoBQ/kcbysqJKgHB9bw/UwsjgySvqqOb8Q2cLnpk8r+3PVScrkhPJqEZK6g0d2/ga+zmd2 8EVxaY/Nb6E/sQ==; In-Reply-To: <87v7vqjexy.fsf@protonmail.com> (message from Pip Cet on Wed, 11 Dec 2024 17:41:29 +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:326376 Archived-At: > Date: Wed, 11 Dec 2024 17:41:29 +0000 > From: Pip Cet > Cc: Gerd Möllmann , 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? And if you are, how is it different from copying stuff lazily within the same process, exactly like the OS does with forked processes? > I know that implementing fork() on Windows is very slow, and I don't > know about a comparable snapshotting mechanism for Windows. I'm not talking about Windows, I'm talking about Posix systems. 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.