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

[Kim F. Storm]

David Kastrup <address@hidden> 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?
>
> 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.

It might be the way for Tramp to do this -- Kai ?


>
> > 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?

I was referring to repeating timers running async handlers related to
things which are not really required to be run on every activation --
such as auto-revert.


A completely different approach would be to NOT run timers from a
timer handler (which may happen because timers are too slow to
execute).

To me, this spells troubles anyway...

I have installed a change to avoid running timers inside a timer.
There may be problems with that change, but let's see if it has
a positive effect on the current problems.

--
Kim F. Storm <address@hidden> http://www.cua.dk