Re: Concurrency via isolated process/thread

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Fri, 07 Jul 2023 20:05:53 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> But how exactly does, say, relocating buffer text can break things? May
> >> you provide a pseudo-code example?
> >
> > ...  If you
> > consider allowing relocation when the buffer is locked, then some of
> > the threads will be surprised when they try to resume accessing the
> > buffer text.
> 
> Can you please provide an example about "surprised"? Do you mean that
> buffer->pt will no longer be accurate? Something else?

Not pt but the pointers to buffer text and the gap.  Those determine
the address of a given buffer position in memory, and are used when a
Lisp program accesses buffer text in any way.  GC can change them if
it decides to relocate buffer text or compact the gap.

> >> Then the question is: can the global state be reduced?
> >
> > By what measures?  Please suggest something concrete here.
> 
> By transforming some of the global state variables into thread-local
> variables.

Which variables can safely and usefully be made thread-local?  I
invite you to look at all the defvar's in the ELisp manual that are
not buffer-local, and consider whether making them thread-local will
make sense, i.e. will still allow you to write useful Lisp programs.
(And if we are thinking about more than one thread working on the same
buffer, then buffer-local variables are also part of this.)

As an exercise, how about finding _one_ variable routinely used in
Lisp programs, which you think can be made thread-local?  Then let's
talk about it.

> >> May it be acceptable to have a limited concurrency where async threads
> >> are only allowed to modify a portion of the global state?
> >
> > I don't see how one can write a useful Lisp program with such
> > restrictions.
> 
> Pure, side-effect-free functions, for example.

I don't see how this could be practically useful.  Besides the basic
question of whether a useful Lisp program can be written in Emacs
using only side-effect-free functions, there's the large body of
subroutines and primitives any Lisp program uses to do its job, and
how do you know which ones of them are side-effect-free or async-safe?
To take just one example which came up in recent discussions, look at
string-pixel-width.  Or even at string-width.