Re: multi-threaded Emacs

[Giuseppe Scrivano <gscrivano@gnu.org>]

Hi Richard,

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

> The main issue about multiple threads in Emacs is,
> when should a thread-switch be possible?  I think it should
> be allowed only where quitting is allowed.  Otherwise,
> internal data can be made inconsistent.
>
> Does pthreads provide the option to forbid thread-switching except
> when the code calls a specific function?  If so, we could make the
> QUIT macro run that function if there is more than one thread.

Internal data shared among threads must be accessed only inside critical
sections in the .c code to have atomic operations on it.
The elisp programmer must not care about what other threads are doing
and using the shared data, only the thread local data is guaranteed to
be accessed only by a thread.
It may seem a limitation but it will allow us a real parallelism with
different threads executed at the same time, in this way we can take
advantage of modern multi-cores machines.

>     (create-thread) 
>     (with-thread id '(code))
>     (kill-thread id)
>
> It seems to me that `with-thread' should be renamed to
> `run-in-thread'.  Meanwhile, `with-thread' should be a macro that
> creates a new thread, starts running the body code in it, and will
> kill it when that body code finishes.
>
> It is un-Lispy to represent threads with numbers.  They should be
> represented by objects that contain info about them.  If there is a
> table of threads, it should not have a fixed size -- it should be
> extended with realloc whenever it gets full.

Right, I used numbers to represent threads (and many other
simplifications) to have quickly something working and understand what
later can be a problem.

> What should happen when another thread gets an error?  Should Emacs
> run the debugger in that thread?  (Probably rather annoying.)  Kill
> the thread?  Leave the thread somehow suspended to be examined (but
> how?).  Kill the thread, and leave some info about the error in the
> dead thread object?  Perhaps there should be a way to specify a choice
> for each thread.

I would avoid something magic and kill the thread.  What do you think
about running the debugger without interrupting the execution of other
threads?
If another thread will get an error then another debugger is executed in
a new buffer.  Potentially every thread can cause the execution of a
debugger in a new buffer and have the possibility to be investigated
separately from others.

> It should not be hard to find all the existing threads and mark all
> their stacks and specpdls.

I like the Stefan's idea of stopping all running threads while the GC is
executed, in this way we can use the current GC without big changes.
At least until a concurrent [parallel] GC will be alive.

Regards,
Giuseppe