[Top][All Lists]

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

Re: Emacs Lisp's future

From: Philipp Stephani
Subject: Re: Emacs Lisp's future
Date: Sun, 09 Oct 2016 13:13:08 +0000

Søren Pilgård <address@hidden> schrieb am So., 9. Okt. 2016 um 14:44 Uhr:
On Sun, Oct 9, 2016 at 2:03 PM, Toon Claes <address@hidden> wrote:

As you can see, introducing concurrency has wide implications for Emacs.

Finding a way to go about it that will still allow old "naive" code to

function correctly is what makes it so tough.

Hopefully we will someday have that, but it requires a lot of hard work.

Maybe we could start out with something like _javascript_s webworkers. A

function running in its own world without access to buffers or other

shared state, and then we could communicate by message passing.

Yes, this is the right approach. It is clear that new threads couldn't be allowed to access existing global state (dynamic variables, buffers, obarray, ...); instead they would need to start with an empty global state.

But as the keen eye would observe that is very similar to simply

spawning an external process.

And it wouldn't benefit much for problems that rely on buffers or global state.

That is a good thing; code should not use global state. Threads should have a properly synchronized method of communicating with each other (e.g. CSP-style channels), but shouldn't be able to access each other's state.

reply via email to

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