unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





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