Re: Introducing thread-safe Tramp

[Dmitry Gutov]

On 7/28/18 1:13 PM, Michael Albinus wrote:
> Dmitry Gutov <address@hidden> writes:
>
> > No objections from me in principle, but we should probably call
> > vc-file-clearprops right away (is there a chance that some other code
> > calls vc-state before this thread launches and gets stale status?).
>
> I've scanned the Emacs lisp dir, and there doesn't seem to be any other
> call to vc-state. If I'm not mistaken.

Third-party code can do that, too. Such as diff-hl, and other packages 
not in GNU ELPA. I don't know if any of them call vc-refresh-state, but 
it would be nice if

(progn
  (vc-refresh-state)
  (vc-state))

always returned a predictable, up-to-date result.

> > We could also make vc-state use the same mutex, in order for it to
> > wait until refresh finished, instead of returning the stale result.
>
> Well, you are much more experienced with vc than I do. Look at the
> changes I've done in vc-hooks.el, and adapt.

I'm not well-versed on the use of Emacs threads, though. Yet.

> The only other relevant change I've done is, that I lock the vc-mutex in
> find-file-with-threads of files.el. This reorders the threads, all
> vc-refresh-state calls are performed after all files (from a wildcard)
> are loaded into their respective buffers. This improves early visibility
> of the visited files.

Do we actually want one global mutex? What if we had one mutex per file? 
Doing those process calls in parallel would be faster, no?