emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Introducing thread-safe Tramp


From: Michael Albinus
Subject: Re: Introducing thread-safe Tramp
Date: Tue, 24 Jul 2018 14:52:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Ken Raeburn <address@hidden> writes:

Hi Ken,

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

Yes. But it might be better to use an own mutex for that.

In Tramp, I have introduced one mutex per connection. Whenever any Tramp
file name operation is called, it goes via `tramp-file-name-handler'. Here
I determine the responsible mutex (according to the connection
characteristics), and I lock this mutex. Once the operation has
finished, at the end of `tramp-file-name-handler', the mutex is
unlocked. (To be honest, I simply use `with-mutex'.)

By this, only one file operation per connection can run at a given
time. This is still better than w/o threads, because if you access
concurrently "/ssh:..." and "/sudo:...", the operations could run in
parallel. And, due to the threads created by find-file, Tramp operations
do not block global editing functions.

Of course, this is a coarse approach. On my todo list is a change, to
apply conection-oriented mutexes not on the file operations level, but
on process related level (sending commands remotely, and retrieve the
output). By this, more concurrency shall be possible, with (hopefully)
better performance. Similar to what you have in mind.

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

Same would be true for Tramp then.

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

Yep. Currently I'm sitting on the problem of handling the minibuffer
properly, when several find-file operations are in progress in
parallel. Something like confirmation of risky local variables in a
file, and alike.

Another problem will be cached values. Tramp caches a lot of file
information, in order to reduce roundtrips. Those cached values might
become invalid due to operations in another thread.

So there's still a lot to do. I hope to get much feedback from you and
other people.

> Ken

Best regards, Michael.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]