From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#19636: [TRAMP] global minor mode hangs connection when accessing files in :lighter Date: Sun, 25 Jan 2015 22:10:30 +0100 Message-ID: <87fvaytvll.fsf@gmx.de> References: <87d268jejx.fsf@gmx.de> <87h9vey7gl.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1422220275 22685 80.91.229.3 (25 Jan 2015 21:11:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Jan 2015 21:11:15 +0000 (UTC) Cc: 19636 <19636@debbugs.gnu.org> To: Philippe Vaucher Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 25 22:11:15 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YFUSg-0007gd-2F for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Jan 2015 22:11:14 +0100 Original-Received: from localhost ([::1]:38927 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFUSf-0000QW-A2 for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Jan 2015 16:11:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFUSa-0000QO-1G for bug-gnu-emacs@gnu.org; Sun, 25 Jan 2015 16:11:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YFUSV-0004qp-1S for bug-gnu-emacs@gnu.org; Sun, 25 Jan 2015 16:11:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFUSU-0004ql-UM for bug-gnu-emacs@gnu.org; Sun, 25 Jan 2015 16:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YFUST-0000UT-Rz for bug-gnu-emacs@gnu.org; Sun, 25 Jan 2015 16:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Jan 2015 21:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19636-submit@debbugs.gnu.org id=B19636.14222202421851 (code B ref 19636); Sun, 25 Jan 2015 21:11:01 +0000 Original-Received: (at 19636) by debbugs.gnu.org; 25 Jan 2015 21:10:42 +0000 Original-Received: from localhost ([127.0.0.1]:56289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YFUS9-0000Tm-Pr for submit@debbugs.gnu.org; Sun, 25 Jan 2015 16:10:42 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:52582) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YFUS5-0000TW-OM for 19636@debbugs.gnu.org; Sun, 25 Jan 2015 16:10:39 -0500 Original-Received: from detlef.gmx.de ([87.146.34.206]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lfppu-1XwNvo3iCw-00pPI3; Sun, 25 Jan 2015 22:10:31 +0100 In-Reply-To: (Philippe Vaucher's message of "Sun, 25 Jan 2015 21:15:44 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-Provags-ID: V03:K0:mcHJBs+mwycxbghwns4ujqwbGcuPg7OwwhxX9GeyW15mI1XSysA 2eQ30L5CPJbQZYOlbltHEfjElBOkFnY7d+JER81r6Ha30LP19TUDs7kOHZz4CYYqSHtd2o8 55e9ELXlx6WKKnp0MT1hliFq81Z/NSE++0u9ywhRz3EhEIVPJfzBKSXIDIqd+GZpSrQmY0C GqRGof5nZtqV363dbJF2w== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:98728 Archived-At: Philippe Vaucher 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.