Re: Introducing thread-safe Tramp

[Ken Raeburn]

On Jul 23, 2018, at 11:58, Michael Albinus <address@hidden> wrote:
> 
> Hi,
> 
> I have created a new branch feature/tramp-thread-safe. The major change
> is making Tramp thread-safe, that means, several basic file operations
> can run concurrently now.

This sounds great!
I haven’t had much time for Emacs work recently but I’ll try to try this out 
soon.

The changes you describe to the find-file interfaces relate to another idea 
I’ve been thinking of for a while, though I wanted to wait until I had time to 
look into it a bit more myself. Namely, make some of the C-level local file 
system interactions release the global lock, and use additional threads for 
invoking some of those operations.

So, for example, while loading a large file from a slow NFS server, we can also 
be processing subprocess output, running garbage collection, etc. If the NFS 
server hangs, ^G should interrupt the main UI thread that’s sitting waiting for 
a notification from the file I/O thread (which is hung until the server comes 
back or the access times out; however, other file I/O threads could be used to 
access other files or file systems), break it out of the wait, and let the user 
go do something else. In auto-save-mode or auto-revert-mode, read/write/stat 
calls shouldn’t cause delays in the UI just because a file server is slow.

There are plenty of details I haven’t worked out, like what to do about these 
background threads acting on a buffer the user is actively modifying at the 
same time. But one thing that had occurred to me was that as far as the user 
interaction is concerned, a multithreaded Tramp would be just the way to try 
out some of these sorts of changes.

Ken