unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Philippe Vaucher <philippe.vaucher@gmail.com>
To: Michael Albinus <michael.albinus@gmx.de>
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 21:15:44 +0100	[thread overview]
Message-ID: <CAGK7Mr6vRSSM909E34z_MRO7YcpTwPNLHveCZeaECn3CjtJRaw@mail.gmail.com> (raw)
In-Reply-To: <87h9vey7gl.fsf@gmx.de>

> > That's an interesting workaround, can I assume that
> > `default-directory` over a TRAMP connection is always absolute? what
> > about symlinks?
>
> You can always assume, that `default-directory' is absolute, being it
> local or remote. Symlinks are not expanded, 'tho.
>
> However, there is always the buffer local variable
> `buffer-file-truename'. Maybe you could use it somehow, when setting the
> lighter? Something like
>
> (if buffer-file-truename (file-name-directory buffer-file-truename) default-directory)

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.


> Short analysis of the debug buffer:
(snip)
> Here Tramp opens a second connection in order to call git.
(snip)
> And here Tramp tries to use the primary connection for getting the
> truename of the default directory. Tramp is not able to accept those
> requests while preparing the second connection for
> start-file-process. Maybe I need to add something in order to make it
> more robust. This is not such easy, it might take time.

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.

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

Thank you!
Philippe





  reply	other threads:[~2015-01-25 20:15 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 [this message]
2015-01-25 21:10         ` Michael Albinus
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=CAGK7Mr6vRSSM909E34z_MRO7YcpTwPNLHveCZeaECn3CjtJRaw@mail.gmail.com \
    --to=philippe.vaucher@gmail.com \
    --cc=19636@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    /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).