Re: multi-threaded Emacs

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I attached a small patch that enables basic threads in Emacs; it is just
> a proof of concept and not usable yet, my goal was the execution of the
> elisp code I included at the bottom.
[...]
> It is a prototype and the code is not very clean, still a lot of work
> must be done in order to have working threads, but I think that have a
> multi-threaded Emacs worths this effort.
[...]
> What do you think about?

I agree that multithreading is a worthwhile goal, even tho it's going to
be a long ride.  It involves several problems:

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

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

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

- 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 ;-).

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


        Stefan