From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Tramp with global-auto-revert-mode. Date: 14 May 2004 21:26:42 +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 1084574269 2065 80.91.224.253 (14 May 2004 22:37:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 14 May 2004 22:37:49 +0000 (UTC) Cc: Kai Grossjohann , Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat May 15 00:37:38 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 1BOlJC-0002Gf-00 for ; Sat, 15 May 2004 00:37:38 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOlJC-0001Uw-00 for ; Sat, 15 May 2004 00:37:38 +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 1BOlB4-0002KV-G2 for emacs-devel@quimby.gnus.org; Fri, 14 May 2004 18:29:14 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BOisx-0000sm-Dn for emacs-devel@gnu.org; Fri, 14 May 2004 16:02:23 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BOiNX-00021s-NK for emacs-devel@gnu.org; Fri, 14 May 2004 15:30:28 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOiKS-00010H-Ng for emacs-devel@gnu.org; Fri, 14 May 2004 15:26:45 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BOiKS-000742-1U; Fri, 14 May 2004 15:26:44 -0400 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: Original-Lines: 66 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:23438 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23438 storm@cua.dk (Kim F. Storm) writes: > 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? The output is yours if nobody else requests it. In short, you work this in the following manner: (if process-is-busy (push my-request process-input-queue) (while (not (member my-request process-output-queue)) (work-on-the-queues))) And work-on-the-queues basically loops around accept-process-output. The filter function correlates the output with the currently running command in the remote shell, writes the results into the process-output-queue and moves the next material from the front of process-input-queue into the shell. > 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 > ...). Do nothing? How is the task accomplished then? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum