Re: Gap buffer problem?

[Dmitry Gutov <dmitry@gutov.dev>]

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.