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

[Kim F. Storm]

David Kastrup <address@hidden> writes:

> Stefan Monnier <address@hidden> writes:
> 
> > > Work properly if they are on a different connection.  Queue them if
> > > they are on the same connection.
> > 
> > Can't queue 'em.
> > 
> > Scenario:
> > 
> >         file-exist-p -> Tramp -> accept-process-output
> >         <<Now process filters and sentinels and timers can be run>>
> >         One of those async thingies calls
> >         file-readable-p -> Tramp -> ????
> > 
> > If it's on the same connection Tramp is stuck: its connection is either
> > busy waiting for some answer from the remote host (which is OK: we can
> > wait) or busy waiting for accept-process-output to return so Emacs can
> > react to the remote process's output; but accept-process-output can't return
> > before file-readable-p is finished.
> 
> So file-readable-p calls accept-process-output, too, which means it is
> effectively queued.  Eventually output arrives.  The problem is that
> the output is for a different operation, but the way "concurrency"
> works in Emacs, the "async thingy" will be the one that is woken up.
> So whoever calls accept-process-output must be prepared to deal with
> preprocessing the accepted output sufficiently so that it can use the
> connection itself.  It would appear that pushing the output into some
> FIFO should do the trick.  Everybody that initiates an operation
> expecting output will call accept-process-output, and then first
> check whether there is something in the FIFO for it.

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?

A simple solution [but probably fully acceptable in practice] would
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
         ...).

Then tramp, ange-ftp, etc. could do

 (let ((remote-busy-p t))
        ...)

-- 
Kim F. Storm  http://www.cua.dk