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: Tue, 19 Sep 2023 07:41:41 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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 possible, but moving point won't induce a redisplay of that
> window.

So if point moves off the window, we will have a window that doesn't
show point?

> > If non-main threads cannot change stuff that affects the display, what
> > can those threads do? compute the 10ⁿ-th digit of π?
> 
> And other tasks like this, responsible for blocking Emacs.  Since most
> of the time, Emacs is not blocked in redisplay, but reading process
> output or performing difficult computations.

Yes, but almost everything we do in Emacs has its purpose of affecting
display, eventually.  Including process output we read and whatever
computations we do.  Emacs is a real-time display editor, first and
foremost, so this should not be a surprise.  The only notable
exception from this rule is batch-style execution in a script.

> > 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?
> 
> Consider the case of Gnus or Eglot: it will enable either of them to
> fetch news or receive LSP output from a second thread, decode it, and
> subsequently transfer it to the main thread for display.

How do you "transfer it to the main thread for display", exactly?  And
won't you want to display some kind of progress indicator while
fetching? or show an error message if things fail?  Every Lisp program
invokes gazillion low-level subroutines and primitives, and some of
those feel free to ask the user questions, show messages, etc.  Even
process.c shows messages,l and modifying a file-visiting buffer might
ask about supersession locks.  We cannot just forbid display from
non-main threads, unless we are willing to rewrite most of the
application code in Emacs, and many of the primitives as well.  The
only solution that avoids the massive rewrite is to invent mechanisms
that still allow non-main threads to communicate with users.

> Such expensive processing is the reason people desire a
> multi-processing Emacs, because it will facilitate efficiently
> running these operations in the background and possibly on a
> different CPU.

I know the theory.  I'm talking about the details -- the devil is
usually there.