[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrency, again

From: Stefan Monnier
Subject: Re: Concurrency, again
Date: Thu, 13 Oct 2016 14:14:55 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

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


> 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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]