emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Kastrup
Subject: Re: Tramp with global-auto-revert-mode.
Date: 14 May 2004 19:54:24 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

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.

Maybe I am too stupid to understand the implications.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]