Re: Very interesting analysis of "the state of Emacs"

[Miles Bader <miles@gnu.org>]

Jonathan Rockway <jon@jrock.us> writes:
> The issue is when we start putting global variables into the mix:
...
> Anyway, hopefully someone has some ideas on what to do here.  I admit I
> haven't looked at how sxemacs handles this yet. Maybe we can just deal
> with locks?  At least in that case my IMAP mail could download while I
> am typing in another buffer :)

If the multi-threading were cooperative (as rms suggested), then such
problems would obviously be a bit easier to manage -- you can basically
just say "no context switches except at well defined points", and define
these "points" to be (1) user interaction/recursive edits [where the
user can do something to "screw up the state" even today], or (2)
explicit calls to yield.

Even with such a restrictive system, I think it's _much_ easier to make
a potentially slow bit of elisp code (gnus or whatever) multi-threadable
by sticking in (yield) calls at strategic places, and of course you'd
make sure that these places were chosen so that any global state
depended on after the yield returns is restricted to places that are
very unlikely to be modified (e.g., if gnus is reading from nntp, for
instance, it could keep all state in its own scratch buffers).

However I think there are potentially additional problems with dynamic
scope:  remember, elisp uses shallow scoping, where binding a variable
is basically "save old value, and set global".  For normal variables,
this could be replaced by deep-binding, which is more multi-threading
friendly (my "lexbind" branch already uses deep-binding in the
interpreter), but afaik, the use of shallow-binding in elisp is kind of
intertwined with the implementation of buffer-local variables and the
like, and I'm not so sure how easy it would be to handle such things
with a new deep-binding implementation.

-Miles

-- 
Admiration, n. Our polite recognition of another's resemblance to ourselves.