Re: Concurrency via isolated process/thread

[Ihor Radchenko <yantar92@posteo.net>]

Po Lu <luangruo@yahoo.com> writes:

>> 1. We can maintain a separate, sparse (just for changed variables)
>>    obarray inside threads, so that `intern'
>>    will point to thread-local symbol objects.
>
> Interning happens at read (and thus load) time.  Byte-code vectors and
> lambdas given to make-thread contain symbols, and not their names.  A
> thread-local obarray will not be helpful.

Fair point. Alas.

>> 3. Store multiple value and function slots in symbol objects.
>
> Why would this be difficult?  It would slow down accesses to value and
> function slots (especially those which aren't bound dynamically), but
> that's an unavoidable drawback of multiprocessing.

Mostly because it will involve more changes than I was hoping for. And I
am not sure how things will affect memory alignment of symbol objects (I
do not fully understand the relevant comments in lisp.h) - we should be
careful about concurrent read access to struct slots in shared objects.
If there is some memory re-alignment happening concurrently, we may
either have to use READ_ONCE (and degrade performance) or be extra
careful to ensure that memory does not get shifted around, and we do not
end up trying to read wrong memory address because some other thread
wrote staff into the same symbol during the read.

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