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 12:04:36 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > GC doesn't only free memory used by dead objects.  It also performs
> > bookkeeping on live objects: compacts data of strings, relocates text
> > of buffers, compacts the gap in buffers where it became too large,
> > etc.  This bookkeeping is more important when Emacs is short on
> > memory: in those cases these bookkeeping tasks might mean the
> > difference between being able to keep the session healthy enough to
> > allow the user to shut down in an orderly fashion.
> 
> What you are describing will only affect subr primitives that work
> directly with C structs and address space.

But that's how _everything_ works in Emacs.  No Lisp runs except by
calling primitives.

> So, we can distinguish two locks: (1) low-level, only available to C
> subroutines; (2) Elisp-level, where the lock merely prevents other Elisp
> code from modifying the data. GC is safe to run when type-2 lock is in
> place as it will never clear the data in use and never alter the data in
> any way visible on Elisp level.

Emacs doesn't know whether some C code which runs was invoked from C
or from Lisp.  (Basically, everything is invoked from Lisp, one way or
another, as soon as we call recursive-edit from 'main' for the first
time after startup.)

> > Locking objects means these bookkeeping tasks will be disabled.  That
> > could adversely affect the available memory and the memory footprint
> > in general.
> 
> I do not think that it is that bad if we consider type-1 locks.

There are no type-1 and type-2 locks.  They are indistinguishable.

> Let's consider the current thread to be thread 2 paused because thread 1
> is doing (setq i ...) at the same time and locked object corresponding
> to obarray variable slot for "i".
> 
> Thread 1 will continue executing until (very soon) it calls maybe_gc
> itself. This time, no further object lock is active and gc may proceed,
> continuing both the threads once GC is done.

You are trying to solve what constitutes a very small, almost
negligible, part of the problem.  The elephant in the room is
something else.