Re: Are there plans for a multi-threaded Emacs?

[Kai Grossjohann]

Miles Bader <address@hidden> writes:

> Consider a simple bit of elisp code:  (setq GLOBAL (cons 'x GLOBAL))
> In a pre-emptively threaded emacs, another thread could run between
> accessing GLOBAL and setting it.  Whoops.

Somebody suggested to avoid this by putting big locks around
everything and then to relax them.

I made the suggestion to "just" let the implementor of the new thread
code worry about such things: if you start a new thread then you're
responsible for letting it run code that doesn't access globals in
problematic ways.

Apparently, the big-lock suggestion is better, but why?

Kai