GNU bug report logs - #19636
[TRAMP] global minor mode hangs connection when accessing files in :lighter

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Philippe Vaucher <philippe.vaucher <at> gmail.com>
Cc: 19636 <19636 <at> debbugs.gnu.org>
Subject: bug#19636: [TRAMP] global minor mode hangs connection when accessing files in :lighter
Date: Sun, 25 Jan 2015 22:10:30 +0100

Philippe Vaucher <philippe.vaucher <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.