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

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 03 Dec 2003, rms@gnu.org wrote:

    > I think migrating Emacs towards a threading model is possible:
> 
>     - start with all primitive or ELisp functions assumed NOT
>       thread-safe
> 
>     - allow threads to run, but any access to a function needs to be
>       synchronous.  At first, this will effectively make threads
>       simple switched tasks, and will probably make Emacs slower.
> 
> Many sections of Lisp code would need to have locking in order
> to run correctly with multiple threads.  For instance, everything
> of the form
> 
>   (setq global-list (cons foo global-list))
> 
> would need locking.

What I proposed is that *all* functions start with the "synchronous"
atribute.  This would apply to primitives as well.

Then, they would be gradually rewritten.  For instance, a thread-safe
setq would act just like the regular setq, but it would lock its
arguments with semaphores before modifying them.  The thread-safe
setq can then be marked "asynchronous."

To deal with the example above, all buffers, variables, processes,
etc. that a synchronous function affects will have to be
thread-locked also.  So that needs to be an extension to my earlier
definition of "synchronous" - not only should concurrent copies of the
same function be forbidden, but also any objects that are used
elsewhere need to trigger thread-locking while the function is in a
scope that involves those objects.  I don't know how feasible that is.

Eventually pieces of code like the above would need to be rewritten
using atomic functions in order to avoid these problems.  For
instance, (push foo global-list) would work better above because the
push function can be made thread-safe.  I know push is not the
perfect example, but the point is that atomic modifications need to
be done atomically.

Ted