Søren Pilgård <fiskomaten@gmail.com> schrieb am So., 9. Okt. 2016 um
14:44 Uhr:

> On Sun, Oct 9, 2016 at 2:03 PM, Toon Claes <toon@iotcl.com> 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 javascripts 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.