Re: Concurrency, again

[Stefan Monnier]

> 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.

> answer the main question -- in my mind, the only question when it comes to
> whether we should consider including this type of support: Will it solve the
> annoyance people have of Emacs blocking when they ask it to do certain things?

Indeed.

> I just want to make sure we're not try to solve the technical problem just
> because it's solvable; we should only solve it if it's a real problem that is
> getting in people's way, or is stopping us from doing the Next Cool Thing.

AFAIK the issue is fairly simple: writing async code (with process
filters/sentinels) in Elisp is rather painful, which is why we have
those blocking situations (which could all be fixed by a "bit" of
rewriting).

So don't think of it as "how can we avoid those breaks" but rather "how
can we make it easier for the programmer to write non-blocking code".

I'm sure it'll break code.  But I think it's worth a try, if only to
convince ourselves that Elisp will never ever move away from the
single-thread world.


        Stefan