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: Fri, 22 Sep 2023 10:48:46 +0000
> 
> >> Again, not always. I do not think that the _initial_ goal should be
> >> making every aspect of Elisp working asynchronously without
> >> interlocking. We certainly want all Elisp to work in threads, possibly
> >> with global lock. But if we get at least some part of useful Elisp to
> >> run truly concurrently, it will already be a win.
> >
> > Not if we want to run the existing Lisp programs in threads with
> > minimal or no changes.  Because Lisp programs we have now require
> > display and user interaction all the time, whether by themselves or by
> > lower-level subroutines they call.
> 
> Sure. _existing_. What I have in mind is programs specifically written
> to take advantage of concurrency. Just to address common performance
> bottlenecks.

If we are talking about an Emacs where programs meant for threads will
need to be written from scratch using special protocols and
primitives, then all bets are off, and I'm not sure everything we
discussed at such a great length lately is at all useful or even
relevant.  The idea was to allow existing Lisp programs run from
threads with little or no changes, by just starting a thread which
runs a function that is already written and debugged when running in
the (single) main thread.  If this is not what you have in mind, try
first to see if users will be likely to switch to such an Emacs or use
such threads, when they know they will need to drop everything and
start from scratch.  Who will want to write a "multithreaded Gnus"
starting from scratch?

> >> I think you misunderstood. I did not mean calling GNU grep. I meant
> >> calling M-x grep - Elisp code searching across many Emacs buffers. It
> >> would be useful if such code could run concurrently.
> >
> > It will be much more useful if it could also show the hits as it runs,
> > instead of requiring the user to wait till it finishes.
> 
> Maybe. But reducing the overall waiting time at the cost of not seeing
> the progress is an OK compromise, IMHO.

If the time is more than, say, a second or two, then no, such a
compromise will not be liked.  At least for Grep-style searches and
other compile-like commands.

> > I'm quite sure people who disregard the display when they are talking
> > about concurrent Lisp threads are going to repeat the same mistake we
> > made with the existing Lisp threads.  We must learn from past
> > experience if we want to succeed.
> 
> What about addressing the existing problems with cooperating Lisp
> threads then?

What about it?  Patches are welcome, of course.  Last time we
discussed these issues, we were unable to find good ideas for solving
them.  Maybe we should try discussing them again.