From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Did something change with respect to Emacs idle loop: Date: Sat, 23 Sep 2006 22:10:16 -0400 Message-ID: References: <17682.1266.569204.546622@gargle.gargle.HOWL> <87k63vg11t.fsf@stupidchicken.com> <17685.29992.39140.92797@gargle.gargle.HOWL> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1159063881 2222 80.91.229.2 (24 Sep 2006 02:11:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 24 Sep 2006 02:11:21 +0000 (UTC) Cc: cyd@stupidchicken.com, 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 04:11:19 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 1GRJSf-0002C5-H3 for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2006 04:11:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRJSf-0007V1-1O for ged-emacs-devel@m.gmane.org; Sat, 23 Sep 2006 22:11:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GRJRs-0007Cm-RH for emacs-devel@gnu.org; Sat, 23 Sep 2006 22:10:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GRJRs-0007CK-7y for emacs-devel@gnu.org; Sat, 23 Sep 2006 22:10:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRJRs-0007CG-3k for emacs-devel@gnu.org; Sat, 23 Sep 2006 22:10:28 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GRJVx-0000da-M1 for emacs-devel@gnu.org; Sat, 23 Sep 2006 22:14:41 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1GRJRg-0006zm-LU; Sat, 23 Sep 2006 22:10:16 -0400 Original-To: raman@users.sf.net In-reply-to: <17685.29992.39140.92797@gargle.gargle.HOWL> (raman@users.sf.net) 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:60156 Archived-At: You'll actually see this when mplayer is playing something off of the local disk while emacs is waiting on an nfs disk Are you saying that the problem ONLY happens when Emacs is waiting for nfs? I think that's what you're saying, but I'm not 100% sure, and I'd like to make sure there is no misunderstanding. If that's the situation, I can guess what the problem might be. Years ago there were uninterruptible waits in NFS code (I am not sure which systems this applied to). That is, a user program (such as Emacs) would do a system call to use NFS, and that system call would wait, and it could not be interrupted until the wait finished. No signals could be delivered. If mplayer is trying to output regularly thru a pty to Emacs, Emacs ought to detect the input and read it every so often. But Emacs can't do that if it is in an uninterruptible wait. So the output buffer would get full, and then mplayer would hang. It would be the same if Emacs is computing without waiting for a long time, since Emacs does not read process output while it is computing. In that case you could fix the problem by calling accept-process-output from time to time. But if NFS causes an uninterruptible wait, there is nothing Emacs can do about it.