bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#19636: [TRAMP] global minor mode hangs connection when accessing fil


From: Michael Albinus
Subject: bug#19636: [TRAMP] global minor mode hangs connection when accessing files in :lighter
Date: Sun, 25 Jan 2015 22:10:30 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

> Thanks for mentionning `buffer-file-truename', I didn't know about it.
> Unfortunately my problem is more complex than that because at the
> moment this package does many files existence checks in order to find
> the project root directory (e.g it tries to find any of "Gemfile",
> ".git", "Makefile" in the current directory, then if not found in the
> parent one, etc). I know that all these filesystem checks doesn't
> scale very well when not done locally, but I'm kinda stuck with the
> current design. It is planned to refactor it all into leveraging
> caching and possibly doing these checks by spawning a little bash
> script remotely.

Out of the Tramp problem, do you know `locate-dominating-file'? It's
designed for that purpose; see for example how it is used in `vc-find-root'.

> Ah, that's very helpful to understand what's going on. What is weird
> is that there seems to be some kind of deadlocking happening, because
> "git fetch" takes less than 10 seconds to finish, and in the log we
> see that it just waits for 10 seconds until the "Are you awake"
> message (I tried increasing the timeout but it just waits until the
> timeout, not processing either the "git fetch" or the `file-truename'.
> It seems that when the second connection starts, if you request
> something that happens to use the first connection, the second
> connection will also be stuck and nothing will happen until the
> timeout is reached.

In the current Tramp design, there can be only up to 2 parallel
connections. The primary one is always used for all file operations, and
the second one is used exclusively for `start-file-process'. So we must
teach `file-truename' and friends to use only the primary connection,
and not the one which is just active.

> So, basically I can see 3 ways to tackle the problem:
>
> - Don't try to do project detection when there's more than one TRAMP
> connection to the same host. Can you point me at a way to do that?
> Something like `(tramp-connections-count default-directory)'

All tests I could tell you are internal to Tramp. Likely, they will
change when I reimplement the connection handling; it's not worth to use
them in your case, therefore.

> - Find a way to detect wether the 2nd connection is "ready", which is
> my attempt with `tramp-connectable-p' or `file-remote-p', but I
> believe this way is a dead-end because TRAMP will tell me about the
> 1st connection and not the 2nd one.

No, not this way. `file-truename' must use the first connection, nothing
else.

> - Fix TRAMP so it better handles multiple connections, but it's likely
> to involve quite some work. Maybe a simple idea would be that calls to
> `file-truename` always use the most recent connection? I'm not sure I
> make sense so feel free to ignore it :)

I will think about. Not sure, whether there will be results very soon.

> Thank you!
> Philippe

Best regards, Michael.





reply via email to

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