From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kai Grossjohann Newsgroups: gmane.emacs.devel Subject: Re: Tramp with global-auto-revert-mode. Date: Fri, 14 May 2004 22:40:49 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <863c62kai6.fsf@slowfox.dyndns.org> 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 1084580238 12444 80.91.224.253 (15 May 2004 00:17:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 15 May 2004 00:17:18 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat May 15 02:17:10 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 1BOmrW-0006pU-00 for ; Sat, 15 May 2004 02:17:10 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOmrV-0003UF-00 for ; Sat, 15 May 2004 02:17:10 +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 1BOlma-0003Hf-Pz for emacs-devel@quimby.gnus.org; Fri, 14 May 2004 19:08:00 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BOkG5-0004Xn-MA for emacs-devel@gnu.org; Fri, 14 May 2004 17:30:21 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BOjxE-0007GL-9v for emacs-devel@gnu.org; Fri, 14 May 2004 17:11:23 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BOjgp-0002xI-G1 for emacs-devel@gnu.org; Fri, 14 May 2004 16:53:55 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by mx20.gnu.org with esmtp (Exim 4.34) id 1BOjdv-0005YP-60 for emacs-devel@gnu.org; Fri, 14 May 2004 16:50:55 -0400 Original-Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BOjdl-0005X2-00 for ; Fri, 14 May 2004 22:50:45 +0200 Original-Received: from pd9e1e7fe.dip.t-dialin.net ([217.225.231.254]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 May 2004 22:50:45 +0200 Original-Received: from kai.grossjohann by pd9e1e7fe.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 May 2004 22:50:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 47 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9e1e7fe.dip.t-dialin.net User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (berkeley-unix) Cancel-Lock: sha1:D0HgQkR3PK47NLNLGfj00J198w0= 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:23457 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23457 storm@cua.dk (Kim F. Storm) writes: > 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? I think that David is suggesting that the timer does not start its own command until the command-in-process is finished. So it goes like this: - User invokes Tramp in some manner. - Tramp sends a command to the remote host and enters a loop calling accept-process-output until the command is complete. (Tramp knows to look for a shell prompt to see that the command is complete.) - This loop is interrupted by a timer. The timer sees that such a loop is in progress already. - The timer enters its own accept-process-output loop, fetching output from the unknown command until the command completes (shell prompt arrives). It stashes the output away someplace safe. - Now the timer is free to do its own thing: it sends a command to the remote end, uses the accept-process-output loop to fetch the result, is happy. - Just before returning, the timer fetches the output from the safe place and inserts it into the connection buffer. Then the timer sends a no-op command to the remote end (but does *not* invoke accept-process-output) and returns. - This is the point in time where the "master" Emacs process gets to do something. It's still inside accept-process-output. The no-op command sent by the timer produces output (a shell prompt) which the now-awakened accept-process-output is happy to receive, and it wakes up. - The master accept-process-output loop sees nothing amiss and just blissfully processes the buffer contents as if nothing strange happened. I hope I got that right. It seems rather fragile to me. Kai