Re: Concurrency via isolated process/thread

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

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

Looks like we have some misunderstanding here, because I do not clearly
see how this kind of catch-all argument can be obvious.

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

Let me elaborate.

What GC is doing may affect C pointers to internal representations of
Elisp objects. But never the Lisp representations.

So, GC running only matters during a subroutine execution. And not every
subroutine - just for a subset where we directly work with internal
object structs.

The subroutines that are GC-sensitive will need to set and release the
object lock before/after they are done working with that object. That
object lock type will be set in C code directly and will not be
available from Elisp.

This approach will, in the worst case, delay the GC by N_threads *
time_between_maybe_gc_calls_in_code. This is a rather small price to pay
in my book. GC is much less frequent (orders less) than the time between
calls to maybe_gc.

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

I suggest to create two distinguishable locks - one that prevents GC and
one that does not. Type-1 will ever only be set from some subset of
C subroutines and will generally not lock for too long. Type-2 can be
set from the Elisp code, can hold for a long time, but will not prevent
GC.

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

Ok. Please, describe the elephant in details. Then, we will be able to
focus on this real big problem.

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