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: Sat, 23 Sep 2023 11:07:54 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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?
> 
> Let me clarify.
> I am not saying that existing Elisp code should not be allowed to run
> from threads. It should.
> 
> However, I think that it can be acceptable to leave certain things
> interlocked - if async thread is querying, for example, user input or
> redisplay, acquire a global (or input/redisplay) lock, and run that
> portion of the thread synchronously.

If this is done under the hood by the infrastructure, and the Lisp
code doesn't have to be modified, this is, of course, fine.

If the Lisp program that wants to interact with the user will need to
do something special when it runs from a non-main thread, that is
worse, but maybe still feasible.

But what can we do about programs that call general-purpose
subroutines, and those subroutines decide to prompt the user?  And
this is the problem which bothers me, because we are used to call many
low-level subroutines without thinking about what that subroutine
will do and whether it will want to prompt the user.

As a trivial example, any function that modifies a file-visiting
buffer could prompt the user if the file was meanwhile modified on
disk.  This prompt is completely out of control of any Lisp program
which does something that modifies buffer text.  How do we handle
these cases? their name is a legion.

> >> 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.
> 
> Are you referring to input discussion? Something else?

I don't know what you mean by "input discussion", but I did already
point you to the relevant discussion, so maybe that is it.

> I think that it could be useful to document problems to be solved in
> etc/TODO.

Feel free.  I don't think I can write something useful for that file,
so I didn't.