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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> A lock on with-current-buffer can't really solve the problem,
> because only a few of the functions that modify a buffer
> use with-current-buffer.

I don't think we can have a fool-proof solution short of using separate
processes with explicit communication.  So my proposal is just to allow
wildly dangerous multi-threading and provide a few synchronising constructs
such that if people really want to, they can write multithreaded code,
although at a cost of extreme care.

> However, perhaps you're thinking of allowing a few specially-designated
> asynchronous threads, each of which would edit only its own buffer or buffers
> so that they won't get in each others' way, that might work if the code
> that runs in these specially-designated threads is specially written to
> be safe in such a thread.

Yes, that's the idea.  I was thinking in terms of "what's the minimal amount
of parallelism needed to get similar benefits as current async-I/O (via
process-filters) but for CPU-bound tasks, such as Gnus's construction of the
summary buffer".  I think in all the important cases, the CPU-bound tasks
runs in a single buffer and that buffer is not modified/used by other code,
so locking at that level makes sense.

> MIGHT be workable.  The devil is in the details, so someone would

Yes, my proposition only addresses the issue from a "threading model for
the elisp programmer" point of view.  Given the extensive internal use of
global variables in the C code, a significant amount of code-review would
be needed to get rid of problems such as the regexp.c code being
non-reentrant, unless we do the preemption manually in Feval and even then,
we'll probably encounter unexpected problems.


        Stefan