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: Sat, 15 May 2004 19:26:09 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <86ekpl61qm.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> <863c62kai6.fsf@slowfox.dyndns.org> <86wu3d7jel.fsf@slowfox.dyndns.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084642684 7597 80.91.224.253 (15 May 2004 17:38:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 15 May 2004 17:38:04 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat May 15 19:37:56 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 1BP36i-00053X-00 for ; Sat, 15 May 2004 19:37:56 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BP36i-0007iT-00 for ; Sat, 15 May 2004 19:37:56 +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 1BP33I-0003SW-Pp for emacs-devel@quimby.gnus.org; Sat, 15 May 2004 13:34:24 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BP32Z-00031F-LS for emacs-devel@gnu.org; Sat, 15 May 2004 13:33:39 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BP31o-0002I1-Tf for emacs-devel@gnu.org; Sat, 15 May 2004 13:33:25 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BP2vQ-0007ur-9u for emacs-devel@gnu.org; Sat, 15 May 2004 13:26:16 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BP2vM-0006Kk-00 for ; Sat, 15 May 2004 19:26:12 +0200 Original-Received: from pd951f40e.dip.t-dialin.net ([217.81.244.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 May 2004 19:26:12 +0200 Original-Received: from kai.grossjohann by pd951f40e.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 May 2004 19:26:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 87 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd951f40e.dip.t-dialin.net User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (berkeley-unix) Cancel-Lock: sha1:IfmgBUWIYwTAMKtx0C1vwR7t5cY= 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:23492 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23492 David Kastrup writes: > Kai Grossjohann writes: > >> David Kastrup writes: >> >> > Uh, much too complicated. >> >> I'm afraid I don't understand you: Do you mean that just the last >> step is too complicated, or that the whole procedure that I described >> is too complicated? > > The whole procedure. Okay. I agree. Though our ideas of simplicity are different -- I was thinking of using multiple connection buffers. >> At some point, I thought I understood what you were suggesting, but >> now I'm not sure anymore. >> >> Let me try to describe my understanding with less detail, then please >> tell me if I got it at least at this level. >> >> Whenever Tramp is invoked, it looks to see if the connection >> buffer is busy. If it is, it knows that Tramp is interrupting >> itself, so to speak. >> >> If this is the case (Tramp is interrupting itself), Tramp "takes >> over" the command in progress, fetches all output from it and >> stashes it someplace safe. > > Look, you are talking all the time about "Tramp" as if it was a > sentient being. It isn't. It must be! It even changed names multiple times, this tells us it knows what it likes. > "Tramp" consists of two entirely different pieces: the user level > routines (of which several can be running at once in different > "threads" or Emacs' equivalence to it) and the filter routine. Those > are basically independent from each other. What is a filter routine? If you are talking about process filters, in the sense of set-process-filter, then there are no filter routines in Tramp. Are you suggesting to change Tramp such that there is a filter routine? [time passes] Oh, I see that Michael added a process filter in one part of Tramp, to support async shell commands. > In order avoid unnecessary lockup in process-send-string, and > problems with identifying responses and input, we might not just > indiscriminately call process-send-string when there are already > outstanding commands. Yes. > Ok, here is what the filter routine does when it is called: it > collects the stuff from the output until it has a completely reply to > the currently sent command available. If it has, it takes the > request and marks it as completed (tacking the results to the > request). > > [Entry point for getting a command on the way:] > It then takes a look whether there are still outstanding commands in > the queue. If there are, it takes the next one from the queue and > sends it through, marking it as being in progress. > > That's all. The filter routine never changes, it does just that. > There is only one filter routine at work at most at any time. > > Now for the user level stuff: it knows it needs to get commands > through. So it makes a request data structure and tacks it to the end > of the current queue (or, if the command is particularly urgent, like > when we are doing autorevert checking, to the _front_ of the current > queue) and then calls accept-process-output on the process repeatedly > until the command finally is marked as being processed. Then it > takes the results and returns. > > That is all. Okay, this is much clearer. Kai