Re: multi-threaded Emacs

[Giuseppe Scrivano]

Hello,

Stefan Monnier <address@hidden> writes:

> - handling thread-specific data: gcprolist, mark_byte_stack, and things
>   like that.  You've tackled this one.  I don't find your solution very
>   elegant, but I can't think of a much better one, unless pthreads does
>   provide some kind of thread-specific variables.  I guess the only
>   improvement is to put those vars together, so we have an array of
>   structs (that then contain gcprolist, and mark_byte_stack fields)
>   rather than several arrays.  And then define `gcprolist' as a macro
>   that expands into "thread_data[current_thread()].gcprolist", so as to
>   reduce the amount of source-code changes.

Yes, we can put thread-specific data together in a struct; what about
buffer data?  `current_buffer' must be different for every thread so as
many other global variables, should it be defined in the same
thread_data struct? 

> - dynamic-scoping: your handling of specpdl is naive and
>   fundamentally flawed.  For multithreading, we will have to completely
>   change the implementation technique of dynamic-scoping.

I know but it was the easier way to have quickly a working
proof-of-concept as I concentrated my efforts mainly on the syntax.
Do you have any idea about how dynamic scoping should be handled in a
multi-threaded environment?

> - synchronization to access all the global variables/objects.
>   You haven't yet have time to tackle this (other than in `put', it
>   seems), and it's going to be difficult.

Why do you think that a global lock (or several ones for separate kind
of data) will not be enough?  It is not easy but I think it can be done
in a reasonable time without many troubles.

> - concurrent GC (later to be refined to parallel concurrent GC ;-).
>
> - redisplay in its own thread (later to be refined to one redisplay
>   thread per terminal, then per frame, then per window ;-).

I think that this is the most difficult part, a new GC and how handle
redisplay.
Different threads can use the same buffer and a buffer can have no
threads actually using it.  I would simplify this part, maybe leave the
redisplay task only to a thread.

> A first step will be to restrict the implementation such that there's no
> parallelism: only one thread executes at any given time (i.e. have
> a single lock and have all thread grab the lock before doing any actual
> work).

IMHO it is better to avoid this middle solution and try to solve
directly the problem, it will not give real benefits and having only one
thread executes at a given time can be done differently, like saving and
restoring the thread call stack.  Real threads will not suffer I/O bound
operations and Emacs will be able to use more cores at the same time, if
needed.

Thanks,
Giuseppe