From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Tramp with global-auto-revert-mode. Date: 14 May 2004 21:08:19 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200405122254.i4CMsUj29445@raven.dms.auburn.edu> <200405122326.i4CNQk929511@raven.dms.auburn.edu> <200405132324.i4DNOBs14811@raven.dms.auburn.edu> <200405140008.i4E08lb14858@raven.dms.auburn.edu> <871xln4xmc.fsf-monnier+emacs@gnu.org> <87oeorb5pq.fsf@emptyhost.emptydomain.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084562394 15402 80.91.224.253 (14 May 2004 19:19:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 14 May 2004 19:19:54 +0000 (UTC) Cc: Kai Grossjohann , Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri May 14 21:19:44 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOiDg-0007CW-00 for ; Fri, 14 May 2004 21:19:44 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOiDg-0006Fn-00 for ; Fri, 14 May 2004 21:19:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOi6Y-0006I3-Em for emacs-devel@quimby.gnus.org; Fri, 14 May 2004 15:12:22 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BOi64-00067U-W3 for emacs-devel@gnu.org; Fri, 14 May 2004 15:11:53 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BOi4o-0005LC-Kj for emacs-devel@gnu.org; Fri, 14 May 2004 15:11:17 -0400 Original-Received: from [193.162.153.9] (helo=pqueuea.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOi3C-0004pp-Dl; Fri, 14 May 2004 15:08:54 -0400 Original-Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by pqueuea.post.tele.dk (Postfix) with ESMTP id E3EA9376522; Fri, 14 May 2004 21:08:53 +0200 (CEST) Original-Received: from kfs-l.imdomain.dk.cua.dk (0x503e2644.bynxx3.adsl-dhcp.tele.dk [80.62.38.68]) by pfepa.post.tele.dk (Postfix) with SMTP id 93B8747FE76; Fri, 14 May 2004 21:08:20 +0200 (CEST) Original-To: David Kastrup In-Reply-To: Original-Lines: 52 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23415 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23415 David Kastrup writes: > Stefan Monnier writes: > > > > Work properly if they are on a different connection. Queue them if > > > they are on the same connection. > > > > Can't queue 'em. > > > > Scenario: > > > > file-exist-p -> Tramp -> accept-process-output > > <> > > One of those async thingies calls > > file-readable-p -> Tramp -> ???? > > > > If it's on the same connection Tramp is stuck: its connection is either > > busy waiting for some answer from the remote host (which is OK: we can > > wait) or busy waiting for accept-process-output to return so Emacs can > > react to the remote process's output; but accept-process-output can't return > > before file-readable-p is finished. > > So file-readable-p calls accept-process-output, too, which means it is > effectively queued. Eventually output arrives. The problem is that > the output is for a different operation, but the way "concurrency" > works in Emacs, the "async thingy" will be the one that is woken up. > So whoever calls accept-process-output must be prepared to deal with > preprocessing the accepted output sufficiently so that it can use the > connection itself. It would appear that pushing the output into some > FIFO should do the trick. Everybody that initiates an operation > expecting output will call accept-process-output, and then first > check whether there is something in the FIFO for it. How does it know where the output from the previous operation ends (or have arrived at all), i.e. how does it know when the output to its own command starts? A simple solution [but probably fully acceptable in practice] would be to have a global remote-busy-p flag that could be tested by async handlers doing file operations - and simply do nothing (in the present activation) if non-nil, i.e. (unless remote-busy-p ...). Then tramp, ange-ftp, etc. could do (let ((remote-busy-p t)) ...) -- Kim F. Storm http://www.cua.dk