Re: Concurrency via isolated process/thread

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> Emm. I meant memory allocation. AFAIK, just like GC allocating heap
>> cannot be asynchronous.
>
> The garbage collector and object allocation can be interlocked, as with
> everything else...

I may be wrong, but from my previous experience with performance
benchmarks, memory allocation often takes a significant fraction of CPU
time. And memory allocation is a routine process on pretty much every
iteration of CPU-intensive code.

I am afraid that interlocking object allocation will practically create
race condition between threads and make Emacs unresponsive.

Or am I missing something?
Is there a way to measure how much CPU time is spent allocating memory?

>> This too, although isn't is already solved by mutexes?
>
> ... which you proceed to admit here, and is the crux of the problem.
> Getting rid of the Lisp interpreter state that is still not thread-local
> (BLV redirects come to mind) is only a minor challenge, compared to the
> painstaking and careful work that will be required to interlock access
> to the rest of the global state and objects like buffers.

Would it be of interest to allow locking objects for read/write using
semantics similar to `with-mutex'?

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