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.