Re: Are there plans for a multi-threaded Emacs?

[Martin Stjernholm]

David Kastrup <address@hidden> wrote:

> It's not preemption, but preemption aware coding, and it does not
> improve parallel execution but is a prerequisite for it.

Maybe we have a terminology problem here. I don't regard thread yields
due to blocking operations or cooperative yielding as preemption.
Instead I reserve that term for uncooperative yielding when a time
slice is up. It's perfectly fine to have several executing tasks in
parallell without ever stopping any of them uncooperatively.

>> Fine grained locking can, but it's hard to avoid making it too fine
>> grained so that the locking itself becomes more time consuming than
>> the speedup from the improved parallellism it achieves.
>
> For that reason it is important to have as few locks necessary as
> possible.  And having to lock on the binding table would be
> prohibitively expensive.

Another reason to have only a single interpreter lock and no
preemption. It's hardly so expensive that it would take significant
time compared to blocking operations, is it?

>> Anyway, a way to cope with such heavy tasks could be to make it easy
>> to fork a separate interpreter with its own data set. It would then
>> only take the main interpreter lock explicitly and rarely to
>> communicate its results and request new data, or perhaps even be
>> restricted to communication through a pipe.
>
> `fork' is a system call that is not available for a considerable
> number of Emacs runtime platforms.

Sorry, I was not entirely clear. I meant only starting a new
interpreter with its own data set in some suitable way, be it with a
thread or a new process. The behavior of the unix fork(2) system call
is actually not very suitable since the new interpreter should not
have a copy of all the data in the original instance.