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

[David Kastrup <dak@gnu.org>]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > Stefan Monnier <monnier@iro.umontreal.ca> 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?

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.

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum