Re: Concurrency via isolated process/thread

[Lynn Winebarger <owinebar@gmail.com>]

On Wed, Jul 5, 2023 at 9:10 AM Ihor Radchenko <yantar92@posteo.net> wrote:
>
> Lynn Winebarger <owinebar@gmail.com> writes:
>
> > The best idea I've had for a general solution would be to make "concurrent"
> > versions of the fundamental lisp objects that act like immutable git
> > repositories, with the traditional versions of the objects acting as
> > working copies but only recording changes.  Then each checked out copy
> > could push charges back, and if the merge fails an exception would be
> > thrown in the thread of that working copy which the elisp code could decide
> > how to handle.  That would work for inter-process shared memory or plain
> > in-process memory between threads.  Then locks are only needed for updating
> > the main reference to the concurrent object.
>
> Honestly, it sounds overengineered.
> Even if not, it is probably easier to implement a more limited version
> first and only then think about fancier staff like you described (not
> that I understand your idea fully).
>

Maybe - I'm not claiming it's trivial.  I do think the locking for
that kind of design is generally much simpler and less prone to
deadlocks than trying to make operations on the current set of
fundamental objects individually atomic.  Given how many lisp objects,
e.g. buffers and functions, are referenceable by name through global
tables, it's difficult to see how emacs could ever have fine-grained
parallelism that's efficient, correct, and deadlock-free any other
way.

The inspiration for this approach (for me) was from reviewing the
version control section of the emacs manual on approaches to
concurrent access.  Version control systems like git are essentially
"concurrent editing in the large".  What is required for emacs is
"concurrent editing in the small", but the issues with sharing and
updating are very much the same.

Lynn