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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: acm@muc.de,  incal@dataswamp.org,  emacs-devel@gnu.org
> Date: Wed, 20 Sep 2023 20:13:49 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't understand why only the main thread is allowed to do that.
> > What is special in the main thread wrt redisplay that other threads
> > are forbidden from doing that?  Would it be okay to have a separate
> > non-main redisplay thread, for example? if not, why not?
> 
> Because toolkits forbid that.  One thread is customarily designated the
> ``main'' thread when the toolkit is initialized, after which any attempt
> to invoke display routines from another thread induces a prompt abort.
> This manifests itself most severely on NS and both GTK builds.

You are talking about the last stage of redisplay: delivering stuff to
the glass.  But xdisp.c is not about that, most of it has no
interaction with the toolkit.

> > They many times happen in the middle of processing, not just
> > "eventually".
> 
> Then the text written to the glass will be inconsistent as long as
> redisplay transpires while processing is still taking place.  Averting
> such situations is not within our purview, but that of authors writing
> Lisp code that exploits threads.

So we drop on the floor the gobs of Lisp code written during the last
40 years, and tell the authors to rewrite everything from scratch
under the new regime?

> > How is this different from telling the main thread to stop, and then
> > doing the display from the thread which triggered that?  IOW, why do
> > we need to ask the main thread to actually display (and perform
> > input), as opposed to just get out of the way for a short while?
> 
> Even with the toolkit problem notwithstanding, we would still have to
> wait for the main thread to enter a section of code where it becomes
> safe to yield to a second thread.  The main thread would then be hung
> until any number of other threads complete redisplay, which IMNSHO
> eliminates the raison d'etre for running multiple threads concurrently.

The same will happen if only the main thread can display.  If a
non-main thread wants to prompt the user, it will have to wait until
the main thread becomes available, prompts the user, and returns the
response.

Someone always has to wait when threads need to synchronize.  There's
no way around that.  Doing this in the thread that needs to
display/prompt is easier because the context and relevant variables
don't need to be communicated to another thread.