On Thu, 16 Jun 2005, [EMAIL PROTECTED] wrote: On 6/16/05, Ted Zlatanov <[EMAIL PROTECTED]> 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 _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
