Re: multi-threaded Emacs

[Giuseppe Scrivano <gscrivano@gnu.org>]

Richard M Stallman <rms@gnu.org> writes:

>     > What is the condition for thread-switching in your latest version?
>
>     The `yield' primitive must be explicitly called.
>
> I think that interface won't work very well, because it would require
> changing every Lisp program to make it cooperate with other threads.
> We need to put this into the C level.

I think it is not safe to call `yield' from the C code, except special
cases like `run-in-thread'.  Every thread must be completely separated
from each other to allow a switch during its execution and it is not
true while threads are accessing global variables.

For example, we can't switch threads while they are executing:

(setq a-global-variable (foo a-global-variable))

This is the reason why YIELD must be explicit at Elisp level, because
the developer knows exactly that a switch can happen at that point.

In future every thread should be executed indipendently from each other
(adding synchronization primitives where they are needed) to allow real
parallelism.


> If making QUIT do this is not safe, we could write another macro
> YIELD to do it, and call that macro where appropriate.
>
> But that macro needs to be very fast when it does NOT switch threads!

Elisp developers shouldn't worry about yield efficiency because if there
are not other active threads, nothing will be done and `yield' returns
immediately.


> Here's an idea.  Suppose the YIELD macro increments a counter and
> switches threads (round robin?) when that counter reaches a certain
> number.  Every thread-switch would reset the counter to 0.
> Of course, waiting (in wait_reading_process_output) would also
> switch threads.

Thread switching is implemented using round robin.  Why would you like
to reduce the amount of switches using a counter?  I think that thread
switching doesn't take a lot of time that we need to call it carefully,
instead I think that more often we call it and more responsive Emacs
will look.
I was thinking about change the scheduler policy to give a bigger
priority to threads that are working on a buffer currently visible to
the user.  What I really expect from Emacs threads is that I can
continue working while some other tasks are executed in the background,
like fetching emails.  Personally I will not care much if it took N+1
seconds instead of N if I could continue work on another buffer.

Giuseppe