Stefan Monnier <
address@hidden> schrieb am Do., 13. Okt. 2016 um 20:15 Uhr:
> I can't think of too many cases where existing Emacs Lisp would immediately
> benefit from being massively parallel, either.
I think the benefit only exists if we want to increasing the
functionality along with the available compute power.
AFAIK single-thread performance has reached a plateau about ten years
ago and there's no sign of its end, and Emacs is "stuck" in
this plateau. Luckily for us, Emacs is far from the only one: very few
programs nowadays know how to take advantage of the extra compute power.
But I see no way to make Emacs take much advantage of parallelism, other
than in completely separate tasks written in other languages
(e.g. a separate executable scanning all a project's files in parallel).
All I was pointing out is that this discussion is about concurrency and
not parallelism.
And that's a very important distinction to make. I think most of the resistance to the concurrency branch in Emacs comes from the fact that it uses OS parallelism primitives such as threads and mutexes to implement cooperative concurrency.
Parallelism indeed appears to be impossible for the foreseeable future; it would require almost a complete rewrite of Emacs. Cooperative concurrency, on the other hand, has a much more limited impact.
I'd suggest to adapt the terminology accordingly: "thread" *can* of course mean "cooperative userland thread", but for most programmers it has come to mean "OS-level parallel thread with preemptive kernel-level scheduling". Should we avoid this term and use "coroutine" instead?