Re: multi-threaded Emacs

[Giuseppe Scrivano <gscrivano@gnu.org>]

Hello,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Currently, we basically use the following implementation:
>
>    (defun get-var (sym)
>      (symbol-value 'var))
>    (defun set-var (sym val)
>      (setf (symbol-value 'var) val))
>    (defmacro let-var (sym val body)
>      `(let ((oldval (get-var ,sym)))
>         (set-var ,sym ,val)
>         (unwind-protect
>             ,body
>           (set-var ,sym ,val))))
>
> we could instead use something like
>
>    (defun get-var (sym)
>      (cdr (assq sym specpdl)))
>    (defun set-var (sym val)
>      (set-cdr (assq sym specpdl) val))
>    (defmacro let-var (sym val body)
>      `(let ((oldpdl specpdl))
>         (push (cons ,sym ,val) specpdl)
>         (unwind-protect
>             ,body
>           (setq specpdl oldpdl))))
>
> where specpdl is a per-thread variable.  Or
>
>    (defun get-var (sym)
>      (cdr (assq thread (symbol-value sym))))
>    (defun set-var (sym val)
>      (set-cdr (assq thread (symbol-value sym)) val))
>    (defmacro let-var (sym val body)
>      `(let ((oldval (get-var ,sym)))
>         (set-var ,sym ,val)
>         (unwind-protect
>             ,body
>           (set-var ,sym ,val))))
>
> This latter one might be the simplest: it basically adapts the
> notion of buffer-local/frame-local/terminal-local to also include
> thread-local.  Currently, only one form of locality is supported at
> a time (a var can't be both buffer-local and terminal-local), so this
> would need to be worked out (frame-local and buffer-local was allowed
> in Emacs-21 but its behavior was not clearly defined and had corner
> case bugs).

I don't think that thread-local data has the same meaning as
buffer-local, frame-local or terminal-local.  Thread-local data should be
handled transparently to the user, I don't see it very useful (if not
dangerous) to give the possibility to store data on a specific thread
beside temporary variables.
Probably it is good idea to modify `with-thread' to don't accept a
thread id, but simply the code to execute on a different thread, the
caller thread local bindings will be copied to the called thread.

Do you see any situation that there is need to store a value on a
specific thread?


> I'm not sure what you mean by "a global lock".  The question is not only
> how many locks, but what they protect.  My proposal further down to
> start with "only one thread active at a time" is what I'd call "a global
> lock".

If we use a lock (or locks) to protect shared data still threads can be
executed in parallel while they working on thread local data.  On the
other hand, with only one active thread we are sure that we are not
forgetting to protect something.


Thanks,
Giuseppe