From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Tramp with global-auto-revert-mode. Date: 14 May 2004 22:33:14 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200405122254.i4CMsUj29445@raven.dms.auburn.edu> <200405122326.i4CNQk929511@raven.dms.auburn.edu> <200405132324.i4DNOBs14811@raven.dms.auburn.edu> <200405140008.i4E08lb14858@raven.dms.auburn.edu> <871xln4xmc.fsf-monnier+emacs@gnu.org> <87oeorb5pq.fsf@emptyhost.emptydomain.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084569043 31890 80.91.224.253 (14 May 2004 21:10:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 14 May 2004 21:10:43 +0000 (UTC) Cc: Kai Grossjohann , Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri May 14 23:10:34 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOjww-0005to-00 for ; Fri, 14 May 2004 23:10:34 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BOjww-0008SN-00 for ; Fri, 14 May 2004 23:10:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOji3-00035Y-PH for emacs-devel@quimby.gnus.org; Fri, 14 May 2004 16:55:11 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BOje7-0002Iq-QD for emacs-devel@gnu.org; Fri, 14 May 2004 16:51:08 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BOjdZ-00027o-Ed for emacs-devel@gnu.org; Fri, 14 May 2004 16:51:05 -0400 Original-Received: from [195.41.46.235] (helo=pfepa.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BOjMz-0007Lg-BM; Fri, 14 May 2004 16:33:25 -0400 Original-Received: from kfs-l.imdomain.dk.cua.dk (0x503e2644.bynxx3.adsl-dhcp.tele.dk [80.62.38.68]) by pfepa.post.tele.dk (Postfix) with SMTP id 10FA247FE03; Fri, 14 May 2004 22:33:15 +0200 (CEST) Original-To: David Kastrup In-Reply-To: Original-Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23421 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23421 David Kastrup 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? > > 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. It might be the way for Tramp to do this -- Kai ? > > > 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? I was referring to repeating timers running async handlers related to things which are not really required to be run on every activation -- such as auto-revert. A completely different approach would be to NOT run timers from a timer handler (which may happen because timers are too slow to execute). To me, this spells troubles anyway... I have installed a change to avoid running timers inside a timer. There may be problems with that change, but let's see if it has a positive effect on the current problems. -- Kim F. Storm http://www.cua.dk