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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Alan Mackenzie <acm@muc.de>,  incal@dataswamp.org,  emacs-devel@gnu.org
> Date: Mon, 18 Sep 2023 21:30:17 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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?
> 
> It can't.  Such adjustments must be performed from the main thread, as
> in all other modern GUI systems.

So a non-main thread cannot do anything that affects the display?
Like move point in a buffer that is shown in some window?

> This is no different from other GUI systems, where calling functions or
> setting variables that affect the UI outside the main thread is strictly
> forbidden, and either gives rise to a prompt crash or aborts with a
> failure indication.  That multiple threads are incapable of sharing
> control over a functioning GUI system is a lesson taught with sweat and
> blood, and for it to be lost on us would be an awful shame.

If non-main threads cannot change stuff that affects the display, what
can those threads do? compute the 10ⁿ-th digit of π?

Useful stuff in Emacs almost always affects the display, so if a
non-main threads cannot do that, they will be useless.  Or what am I
missing?

> Just two cents from someone who actually _HAS_ a multi-processing Emacs
> in a quasi-functional state.

IMNSHO, if you left the display issues unsolved, you are no closer to
the solution than we are in Emacs 30.