Re: Threads in emacs implementation

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 16 Jun 2005, snogglethorpe@gmail.com wrote:

On 6/16/05, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> I'm not sure I understand the problem.  Do you mean that if a user
>> changes variable A in thread 1, he expects thread 2 to also notice the
>> change for certain global variables?  That's easy to do, if you
>> consider that such global variables are few and far between compared
>> to local per-thread variables.
> 
> This is not really true for typical elisp programs -- global variables
> (especially buffer-local global variables) are used extremely often,
> and in almost every case must be "truly global" (visible in all
> threads).

At the time of the fork, the thread will pick up all globals.  I was
talking about important globals that are modified after the fork.  At
least my experience has been that after you initialize Emacs, it's
rare to modify globally important variables unless you are
specifically customizing Emacs.

By far, I'm not as experienced with Emacs internals and packages as
you and many others on this list, so please excuse any dumb
suggestions :)

> However, if a global variable is let-bound, the let-binding should
> of course be thread-local.

Yes.  Perhaps let-bindings will end up being the only thread-local
bindings and the VM will pay the stack penalties RMS mentioned.  I
just hope it doesn't have to be that way.

> My personal feeling is that it may be easiest to simply move to a
> deep-binding system for elisp (and ideally use lexical-binding for
> local variables), but such a change may be a lot of work given the
> myriad special varieties of variable bindings (buffer-local etc).

Whatever the path, I'm just excited that others have picked up on the
multithreading Emacs idea, and I'll be glad to contribute what I can
to the effort.

Ted