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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Alan Mackenzie <acm@muc.de>, incal@dataswamp.org, emacs-devel@gnu.org
> Date: Mon, 18 Sep 2023 12:49:21 +0000
> 
> > I'm confused: suppose one thread modifies scroll-margin -- does that
> > affect the (global) redisplay?  If it does, how will this "solve" the
> > problem?  If it doesn't affect redisplay, how _can_ a thread change
> > scroll-margin in order to affect redisplay?
> 
> IMHO, the only sane way to utilize the existing redisplay is redisplay
> lock - only one thread can request redisplay at a time, using its
> thread-local state.

So if one thread changes scroll-margin and triggers redisplay, then
another thread triggers redisplay with its (different value of
scroll-margin), the display will scroll or move point back? and then
forward again? and then back again?

> >> I don't think several redisplay threads would be a good idea - usually,
> >> there is just one screen Emacs is drawing on.
> >
> > It's one screen, but each window is redrawn separately (on GUI
> > terminals).
> 
> Technically yes, but AFAIU the code is written assuming single-threaded
> execution.

In what way does it assume single-threaded execution?  We walk the
window tree of a frame and redisplay each leaf window in the tree,
that's all.  Maybe I don't understand what you mean by "assuming
single-threaded execution".

> Decoupling redisplay of different windows would require significant
> non-trivial changes in xdisp.c

In which part(s) of xdisp.c?  Most of xdisp.c handles redisplay of a
single window.