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: 15 May 2004 20:18:13 +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> <863c62kai6.fsf@slowfox.dyndns.org> <86wu3d7jel.fsf@slowfox.dyndns.org> <86ekpl61qm.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 1084645401 12407 80.91.224.253 (15 May 2004 18:23:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 15 May 2004 18:23:21 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat May 15 20:23:11 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 1BP3oT-0006s9-00 for ; Sat, 15 May 2004 20:23:09 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BP3oT-0000QD-00 for ; Sat, 15 May 2004 20:23:09 +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 1BP3lS-0004Tg-0C for emacs-devel@quimby.gnus.org; Sat, 15 May 2004 14:20:02 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BP3kL-00046z-Ku for emacs-devel@gnu.org; Sat, 15 May 2004 14:18:53 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BP3jl-0003vu-JU for emacs-devel@gnu.org; Sat, 15 May 2004 14:18:49 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BP3jl-0003vl-2i for emacs-devel@gnu.org; Sat, 15 May 2004 14:18:17 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BP3jk-0006Ev-36; Sat, 15 May 2004 14:18:16 -0400 Original-To: Kai Grossjohann In-Reply-To: <86ekpl61qm.fsf@slowfox.dyndns.org> Original-Lines: 90 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:23497 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23497 Kai Grossjohann writes: > 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. Those have to be set up and initialized. You know that Tramp initialization takes a _lot_ of time. If we have some timer-related events, it is likely that we will get an indefinite stack of sessions all occupied with initializing a connection. > > 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. Pffft. With that sort of reasoning, XEmacs aka Lucid Emacs aka Emacs19-to-be-well-at-some-time-we-thought-so would be three times as intelligent as Emacs. Don't bother commenting on that: it's no fun starting a flame war if we are all supposed to be on the same side. > > "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. Oh, I see. Well, it doesn't matter, strictly speaking. Whoever calls accept-process-output should feel qualified, when being woken up, to do the work of the non-existent process-filter, and if after that its own task has not been finished (or even started), call accept-process-output again. > Are you suggesting to change Tramp such that there is a filter > routine? Whether you call the routine by an actual process-filter, or some task having called accept-process-filter does it, does not make _much_ of a difference. However, a separate process filter can be called at slightly more times than an accept-process-filter task can be woken up, (because the process filter starts without a personal stack frame, and thus need not be "on top" of the stack), so the process filter approach would probably provide a lower latency. > > 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. Of course, if the shell is idle at the time that a command has been entered into the queue, the user level routine should manually call the above "Entry point for getting..." before relapsing into accept-process-output, or nothing will get done, ever. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum