Re: Emacs design and architecture. How about copy-on-write?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org
> Date: Tue, 19 Sep 2023 11:36:24 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Nope. I consider that redisplay is always synchronous
> >
> > Synchronous to what?
> 
> Synchronous in a sense that no two `redisplay' calls can be executed in
> parallel.

I think they can, if they display different buffers in different
windows.

> >> (because of global redisplay lock)
> >
> > What is the global redisplay lock?
> 
> I imagine that the implementation can involve global redisplay lock that
> `redisplay' (or its internal functions) need to acquire before running.

I thought you were describing the current implementation (where
there's no lock).  If you are describing some hypothetical future
implementation, I don't see how we could usefully discuss this without
much more details of that hypothetical design.

> >> 3. xdisp is relying on a number of global-only variables like
> >>    `mode-line-compact', `show-trailing-whitespace', and similar.
> >>    AFAIR, things like `show-trailing-whitespace' affect how the
> >>    optimizations are applied when deciding which windows should be
> >>    redisplayed and which should not. I suspect that logic related to
> >>    optimizations may be very fragile with async execution.
> >
> > That's completely irrelevant to the issue at hand.  The fact that
> > Emacs has a huge global state, and all of its code relies on that is a
> > separate issue.  Here, I asked you in what sense is xdisp.c's code
> > single-threaded; if your answer is "because of its reliance on global
> > state", it means there's no separate problem of xdisp.c that is based
> > on single thread.
> 
> Then, we had a misunderstanding. My point is exactly that xdisp.c relies
> on global state _a lot_. And it will be non-trivial to change it.

It doesn't _rely_ on the state, not on the level of the code.  It
_accesses_ the state as every other Lisp program does, since that's
how Emacs accesses it everywhere.  But there are no hidden assumptions
that the variables used by xdisp.c are global.  If each one of them
will become buffer-local or thread-local, nothing significant will
change in the xdisp.c code.  All xdisp.c needs is to be able to access
the value when needed.  And since each window is processed separately,
there's no assumption that something observed when displaying window
W1 will necessarily hold when displaying window W2.

> In my mind, it is easier to first solve the problem with generic Elisp
> async threads and only then try to look into async redisplay.

We tried that already, with the existing Lisp threads.  One reason why
those are almost never used is that the display issue was left
unresolved.  Any real-life Lisp programs that tries to use threads
bumps into this issue sooner or later.