Re: Introducing thread-safe Tramp

[Michael Albinus]

Dmitry Gutov <address@hidden> writes:

Hi Dmitry,

> 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.

vc-refresh-state works over the current buffer, vc-state works over a
file (which is missing in your example). I don't see after a short look
in the sources, how they depend. The result of your code snippet would
always be the result of vc-state, which is not threaded.

>> 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.

Me too, some weeks ago :-) It isn't that hard.

>> 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?

One mutex per file isn't necessary; vc-refresh-state is already blocked
per file (buffer), because it is called only at the very end of any file
visiting command.

But you are right, the vc-refresh-state calls shall run in parallel. So
I have changed to lock them via vc-mutex only at thread entry, unlock
happens immediately. This still ensures that all vc-refresh-state
threads run only after all files have been loaded into their buffers,
but then they can run in parallel.

Best regards, Michael.