Stefan Monnier <monnier@iro.umontreal.ca> 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?