From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: Did something change with respect to Emacs idle loop: Date: Sun, 24 Sep 2006 17:49:35 +0200 Message-ID: References: <17682.1266.569204.546622@gargle.gargle.HOWL> <87k63vg11t.fsf@stupidchicken.com> <17685.29992.39140.92797@gargle.gargle.HOWL> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1159113028 10258 80.91.229.2 (24 Sep 2006 15:50:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 24 Sep 2006 15:50:28 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 24 17:50:25 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 1GRWFF-0004Bi-HB for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2006 17:50:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRWFE-0007la-Bx for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2006 11:50:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GRWF0-0007lD-MF for emacs-devel@gnu.org; Sun, 24 Sep 2006 11:50:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GRWEz-0007kj-3s for emacs-devel@gnu.org; Sun, 24 Sep 2006 11:50:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRWEy-0007kP-UM for emacs-devel@gnu.org; Sun, 24 Sep 2006 11:50:00 -0400 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GRWJB-0001S3-VI for emacs-devel@gnu.org; Sun, 24 Sep 2006 11:54:22 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GRWEr-00046n-LT for emacs-devel@gnu.org; Sun, 24 Sep 2006 17:49:53 +0200 Original-Received: from ua-83-227-131-3.cust.bredbandsbolaget.se ([83.227.131.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Sep 2006 17:49:53 +0200 Original-Received: from joakim by ua-83-227-131-3.cust.bredbandsbolaget.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Sep 2006 17:49:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 40 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ua-83-227-131-3.cust.bredbandsbolaget.se User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.51 (gnu/linux) Cancel-Lock: sha1:pISuMJjwtgvI45VEpltkUtcAcUk= 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:60167 Archived-At: Richard Stallman writes: > 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. I obeserved the same problem some time ago when I was using EMMS(emacs multimedia system) and mplayer. Mplayer output would stop while Gnus was doing something network oriented, because Mplayer couldnt print its output. The solution in my case was to use a player that didnt rely on being able to print messages to generate audio output. (Mplayer can still be used with its remote control mode) -- Joakim Verona http://www.verona.se