From: Michael Albinus <michael.albinus@gmx.de>
To: Philippe Vaucher <philippe.vaucher@gmail.com>
Cc: 19636 <19636@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 [thread overview]
Message-ID: <87fvaytvll.fsf@gmx.de> (raw)
In-Reply-To: <CAGK7Mr6vRSSM909E34z_MRO7YcpTwPNLHveCZeaECn3CjtJRaw@mail.gmail.com> (Philippe Vaucher's message of "Sun, 25 Jan 2015 21:15:44 +0100")
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.
next prev parent reply other threads:[~2015-01-25 21:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 17:49 bug#19636: [TRAMP] global minor mode hangs connection when accessing files in :lighter Philippe Vaucher
2015-01-21 16:15 ` Michael Albinus
2015-01-21 17:40 ` Philippe Vaucher
2015-01-22 11:07 ` Philippe Vaucher
2015-01-25 19:40 ` Michael Albinus
2015-01-25 20:15 ` Philippe Vaucher
2015-01-25 21:10 ` Michael Albinus [this message]
2015-01-25 21:47 ` Philippe Vaucher
2017-03-25 20:43 ` Philippe Vaucher
2017-03-27 13:36 ` Michael Albinus
2017-03-27 15:46 ` Philippe Vaucher
2017-07-14 13:12 ` Michael Albinus
2017-07-21 12:56 ` Philippe Vaucher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fvaytvll.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=19636@debbugs.gnu.org \
--cc=philippe.vaucher@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).