Re: Concurrency via isolated process/thread

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> AFAIU, one of the big blockers of this is single-threaded GC. Emacs
>> cannot free/allocate memory asynchronously. Or do I miss something?
>
> Why is that a "big blocker"?  GC runs "whenever it is convenient"
> anyway, so it can be delayed until that time, and run from the main
> thread, perhaps sacrificing the memory footprint a bit.

Emm. I meant memory allocation. AFAIK, just like GC allocating heap
cannot be asynchronous.

For the GC, most of the memory objects in long-running Emacs sessions
are short-living. So, having a separate GC and memory heap in async
process will likely improve the main thread performance GC-wise, as a
side effect.

> The real "big blocker" is that a typical Emacs session has a huge
> global state, which cannot be safely modified by more than a single
> thread at a time, and even if one thread writes while the other reads
> is in many cases problematic.

This too, although isn't is already solved by mutexes?

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