Re: Concurrency via isolated process/thread

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Thu, 06 Jul 2023 16:17:02 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> This does not change my understanding.
> >> Locking should prevent manipulations with object data over the time span
> >> the code expects the object to be unchanged.
> >
> > That could defeat GC, should Emacs decide to run it while the lock is
> > in place.
> 
> May you elaborate?

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.

Locking objects means these bookkeeping tasks will be disabled.  That
could adversely affect the available memory and the memory footprint
in general.

> Of course, GC calls must not be done while Object lock is in place. But
> that's not too different from the existing requirement for GC calls -
> they are not sprinkled in arbitrary places.

Currently, once GC starts it is free to do all of its parts.  If
locking prevents GC altogether, your proposal is even worse than I
feared.  Especially since as long as some thread runs, some objects
will be locked, and GC will not be able to run at all.