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

[Martin Stjernholm]

Ted Zlatanov <address@hidden> wrote:

> On Fri, 05 Dec 2003, address@hidden wrote:
>
>> Reading or writing are blocking operations, so they would be
>> executed in parallel anyway.
>
> Right, but if the read or write don't need to block the UI thread, why
> should they?

I didn't say they should, rather the opposite. Maybe I wasn't entirely
clear: They would be executed in parallel even with the single lock
approach.

Emacs would handle each event in a different thread (using a thread
pool, probably, since starting threads often aren't cheap) so that the
main thread always remains idle and can respond to new events. Due to
the single lock, there would still be no concurrency problems in code
that isn't adapted.

It's just a matter of reviewing the most important places doing
blocking I/O and turn on unlocked operation there (if it isn't turned
on by default). Note that only the actual system call is run unlocked,
so no surrounding C or elisp code needs to be adapted with locks. What
needs to be done in the review is to add code that rechecks the state
afterwards and fails gracefully if it has changed too much.

A nice thing is that this is opt-in; there's no need to go through and
thread safe everything - even if it only is enabled in a few common
places there's an improvement in responsiveness.