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

[David Kastrup]

Kai Grossjohann <address@hidden> writes:

> address@hidden (Kim F. Storm) 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?
> 
> I think that David is suggesting that the timer does not start its
> own command until the command-in-process is finished.  So it goes
> like this:
> 
> - User invokes Tramp in some manner.
> 
> - Tramp sends a command to the remote host and enters a loop calling
>   accept-process-output until the command is complete.  (Tramp knows
>   to look for a shell prompt to see that the command is complete.)
> 
> - This loop is interrupted by a timer.  The timer sees that such a
>   loop is in progress already.
> 
> - The timer enters its own accept-process-output loop, fetching
>   output from the unknown command until the command completes (shell
>   prompt arrives).  It stashes the output away someplace safe.
> 
> - Now the timer is free to do its own thing: it sends a command to
>   the remote end, uses the accept-process-output loop to fetch the
>   result, is happy.
> 
> - Just before returning, the timer fetches the output from the safe
>   place and inserts it into the connection buffer.  Then the timer
>   sends a no-op command to the remote end (but does *not* invoke
>   accept-process-output) and returns.
> 
> - This is the point in time where the "master" Emacs process gets to
>   do something.  It's still inside accept-process-output.  The no-op
>   command sent by the timer produces output (a shell prompt) which
>   the now-awakened accept-process-output is happy to receive, and it
>   wakes up.

Uh, much too complicated.  accept-process-output does _not_ read any
process-output.  It just puts a process to sleep until something has
been processed.  Since it is not processing the output itself (but
relies on a filter function or the default buffer insertion to do so),
we don't need any do-nothing commands or whatsoever.  When output
arrives, the currently active filter function will be called with it
and _all_ accept-process-output calling threads will get woken up
again.  So they will need to check whether their respective work has
already been done or aborted by the filter routine.

> I hope I got that right.

Too complicated, I guess.

> It seems rather fragile to me.

Same here.  The filter routine just should just mark the last command
sent to the remote shell as finished, and then see whether any
job/command is still pending.  If yes, it sends it.

Every accept-process-output checks whether its job is finished, in
which case it returns, has been dequeued by force (closed connection
whatever) in which case a signal is probably thrown, or is either
still in queue or currently in progress.  In which case
accept-process-output is called again.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum