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

[David Kastrup <dak@gnu.org>]

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.

Maybe I am too stupid to understand the implications.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum