Re: Tramp with global-auto-revert-mode.

[David Kastrup <dak@gnu.org>]

Kai Grossjohann <kai.grossjohann@gmx.net> writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > Kai Grossjohann <kai.grossjohann@gmx.net> writes:
> >
> >> David Kastrup <dak@gnu.org> 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