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

[Martin Stjernholm <mast@lysator.liu.se>]

Kai Grossjohann <kai@emptydomain.de> wrote:

>>> I made the suggestion to "just" let the implementor of the new thread
>>> code worry about such things: if you start a new thread then you're
>>> responsible for letting it run code that doesn't access globals in
>>> problematic ways.
>>
>> Would a thread like that be used from the elisp level?
>
> That was my idea.

I think a very sound design principle is to keep apart errors on
different implementation levels. I.e. bugs on a higher level shouldn't
have effects on a lower. E.g. if you make an elisp error, say moving
the point and changing the same buffer from two threads, you shouldn't
get an internally inconsistent buffer state which likely will cause
Emacs to dump core later on or disbehave in subtle ways (maybe some
markers get lost and simply cease to be kept up-to-date). The elisp
programmer would have a hard time tracking down an error like that,
and would probably report it as a bug in the core instead.

Another problem related to that is that the elisp programmer would
need to have extensive knowledge of the internals to know what would
be safe to do. For instance, all buffers are linked together, which
means there would probably be a race simply creating a new buffer from
a thread. That's not obvious to the elisp programmer - buffers appear
to be independent entities in elisp.

Also, it wouldn't only be a matter of adding a `create-thread' elisp
function and leave the rest to the elisp hacker. It'd still be
necessary to do away with the global state used directly by the
interpreter, e.g. the binding environment (which I've gathered is
global now). I.e. potentially a lot of global variables would have to
be moved to some thread state struct, and all the code that access
them must be updated accordingly. Something similar would of course be
necessary for the single lock solution too, but in that case it would
suffice to have swap functions that copies and restores the global
state from a thread state struct, so the code that uses global
variables wouldn't have to be changed.

I also suspect the garbage collector would be a problem if it isn't
inherently thread safe. It probably needs to have a lock that excludes
all other activities while it runs.