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 18:24:04 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> May you please provide a concrete example how running GC breaks things?
> >
> > I already did: see my description of compacting strings, relocating
> > buffer text, and other stuff GC does.
> 
> But how exactly does, say, relocating buffer text can break things? May
> you provide a pseudo-code example?

If by "lock the buffer" you mean that buffer text cannot be relocated,
then you hurt GC and eventually the Emacs memory footprint.  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.

> >> I am interested in specific details. The way you say it now is general
> >> and sounds like "it is impossible and there is no point trying to do
> >> anything".
> >
> > That's indeed what I want to say.  You cannot have true concurrency as
> > long as Emacs Lisp programs use this huge global state.
> 
> Then the question is: can the global state be reduced?

By what measures?  Please suggest something concrete here.

> 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.