From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "T. V. Raman" Newsgroups: gmane.emacs.devel Subject: Re: Did something change with respect to Emacs idle loop: Date: Sun, 24 Sep 2006 10:58:53 -0700 Message-ID: <17686.51037.392205.489386@gargle.gargle.HOWL> References: <17682.1266.569204.546622@gargle.gargle.HOWL> <87k63vg11t.fsf@stupidchicken.com> <17685.29992.39140.92797@gargle.gargle.HOWL> Reply-To: raman@users.sf.net NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1159120656 31389 80.91.229.2 (24 Sep 2006 17:57:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 24 Sep 2006 17:57:36 +0000 (UTC) Cc: cyd@stupidchicken.com, raman@users.sf.net, emacs-devel@gnu.org, raman@users.sourceforge.net Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 24 19:57:32 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GRYEI-0002rn-28 for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2006 19:57:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRYEH-0006Xh-N2 for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2006 13:57:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GRYE4-0006To-2K for emacs-devel@gnu.org; Sun, 24 Sep 2006 13:57:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GRYE2-0006SG-8u for emacs-devel@gnu.org; Sun, 24 Sep 2006 13:57:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRYE2-0006S4-50 for emacs-devel@gnu.org; Sun, 24 Sep 2006 13:57:10 -0400 Original-Received: from [204.127.200.83] (helo=sccrmhc13.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GRYIF-0005HA-OC; Sun, 24 Sep 2006 14:01:31 -0400 Original-Received: from localhost (c-71-202-191-236.hsd1.ca.comcast.net[71.202.191.236]) by comcast.net (sccrmhc13) with ESMTP id <200609241757020130043lmse>; Sun, 24 Sep 2006 17:57:07 +0000 Original-Received: by localhost (Postfix, from userid 1000) id 71F1CE08001; Sun, 24 Sep 2006 10:58:53 -0700 (PDT) Original-To: rms@gnu.org In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.0.50.6 x-attribution: tvr X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:60171 Archived-At: What you say below helps me understand the hangs in the context of NFS better, but that problem has been there before I reported this particular problem. What I was trying to say was: The hangs I'm seeing when the new alleged bug bites on my ubuntu box (where there is no nfs at present) is similar to what I've seen mplayer do on systems that do have nfs. The hangs are going away on the ubuntu box the moment I touch the keyboard. >>>>> "Richard" == Richard Stallman writes: Richard> You'll actually see this when mplayer is playing Richard> something off of the local disk while emacs is Richard> waiting on an nfs disk Richard> Richard> Are you saying that the problem ONLY happens when Richard> Emacs is waiting for nfs? I think that's what Richard> you're saying, but I'm not 100% sure, and I'd like Richard> to make sure there is no misunderstanding. Richard> Richard> If that's the situation, I can guess what the Richard> problem might be. Richard> Richard> Years ago there were uninterruptible waits in NFS Richard> code (I am not sure which systems this applied to). Richard> That is, a user program (such as Emacs) would do a Richard> system call to use NFS, and that system call would Richard> wait, and it could not be interrupted until the wait Richard> finished. No signals could be delivered. Richard> Richard> If mplayer is trying to output regularly thru a pty Richard> to Emacs, Emacs ought to detect the input and read Richard> it every so often. But Emacs can't do that if it is Richard> in an uninterruptible wait. So the output buffer Richard> would get full, and then mplayer would hang. Richard> Richard> It would be the same if Emacs is computing without Richard> waiting for a long time, since Emacs does not read Richard> process output while it is computing. In that case Richard> you could fix the problem by calling Richard> accept-process-output from time to time. But if NFS Richard> causes an uninterruptible wait, there is nothing Richard> Emacs can do about it. Richard> -- Best Regards, --raman Email: raman@users.sf.net WWW: http://emacspeak.sf.net/raman/ AIM: emacspeak GTalk: tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc Google: tv+raman IRC: irc://irc.freenode.net/#emacs