Re: Concurrency via isolated process/thread

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Tue, 25 Jul 2023 11:52:32 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Of course, such write locks should happen for short periods of time to
> >> be efficient.
> >
> > How can this be done in practice?  Suppose a Lisp program needs to
> > access some object, so it locks it.  When will it be able to release
> > the lock, except after it is basically done?  because accessing an
> > object is not contiguous: you access it, then do something else, then
> > access it again, etc. -- and assume that the object will not change
> > between successive accesses.  If you release the lock after each
> > individual access, that assumption will be false, and all bets are off
> > again.
> 
> This is just a basic problem with any kind of async code.

Async code avoids accessing the same object as much as possible, and
if that's not possible, uses synchronization features.  You also
suggest using synchronization feature, and there's nothing wrong with
that -- except that if those are used to lock buffers and global
objects, we no longer have true concurrency, because in many cases
only one thread will be able to do something useful.  That is all I'm
saying.  If you agree, then this whole development sounds
questionable, because it will require massive changes for very little
practical gain, and with many disadvantages, like the necessity to
call synchronization primitives from Lisp (which makes it impractical
to run the same Lisp program with and without concurrency).

Bottom line: I think your view of what will need to change vs what
will be the costs is very optimistic.  We have only scratched the
surface of the subject, and already there are quite serious issues and
obstacles to be negotiated.  Feel free to work on devising solutions,
but my gut feeling is that this is not worth it, and that Emacs cannot
be adapted to true concurrency without a very thorough redesign of the
core data structures and rethinking of the main architectural
assumptions and models.  E.g., do we even believe that MVC is a proper
architecture for a multithreaded program?

And one other remark: please always keep in mind that Emacs is unusual
in the depth and intensity of the control it lets Lisp programs have
on both input and display.  Any significant architectural change will
have to live up to the expectations of Lisp programmers who are used
to the level of control they have in Emacs.  Providing the same level
of control when input and display run in separate threads from the
Lisp machine, let alone allowing several Lisp threads run in parallel
and complete for such control, might prove much more difficult.  But
if not provided, this will no longer be Emacs, and will not be as
popular with the present community.  That's an additional uphill
battle any new design will have to fight.