Re: Concurrency via isolated process/thread

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

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

What you are describing will only affect subr primitives that work
directly with C structs and address space.

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.

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

Consider two parallel threads:

----- 1 ------
(let ((i 0)) (while t (cl-incf i)))
--------------

----- 2 -----
(while t (read-char))
-------------

Both the threads will call eval_sub frequently that will trigger
maybe_gc.

I consider that maybe_gc, when decided that GC is necessary, but cannot
continue because an object is locked using type-1 lock, will pause the
current thread.

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.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>