emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gap buffer problem?


From: Dmitry Gutov
Subject: Re: Gap buffer problem?
Date: Thu, 12 Dec 2024 00:07:16 +0200
User-agent: Mozilla Thunderbird

On 11/12/2024 21:54, Pip Cet via Emacs development discussions. wrote:

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).

Could one really avoid global interpreter lock using fork()? It doesn't sound right: even if you get cheap snapshotting using the underlying OS's mechanisms, could we guarantee that the snapshot is "consistent" from the Lisp VM's point of view. Or if Lisp were not in the picture, that the data structures are consistent anyway, unless the second process adheres to the first one's locks anyway.

But, to be perfectly honest, I'm not sure redisplay is slowing me down
the way traditional GC is.

IMO redisplay is not the problem most of time indeed. Sometimes it is, but I'm not sure parallelizing the rendering is the best answer in those scenarios either.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]