all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "T. V. Raman" <raman@users.sf.net>
Cc: cyd@stupidchicken.com, raman@users.sf.net, emacs-devel@gnu.org,
	raman@users.sourceforge.net
Subject: Re: Did something change with respect to Emacs idle loop:
Date: Sun, 24 Sep 2006 10:58:53 -0700	[thread overview]
Message-ID: <17686.51037.392205.489386@gargle.gargle.HOWL> (raw)
In-Reply-To: <E1GRJRg-0006zm-LU@fencepost.gnu.org>


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 <rms@gnu.org> 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

  parent reply	other threads:[~2006-09-24 17:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-21  3:20 Did something change with respect to Emacs idle loop: T. V. Raman
2006-09-21  3:47 ` T. V. Raman
2006-09-21 13:58   ` Romain Francoise
2006-09-22  1:11     ` T. V. Raman
2006-09-22 18:08       ` Romain Francoise
2006-09-22  4:11 ` Richard Stallman
2006-09-22 19:21   ` Chong Yidong
2006-09-23 17:55     ` T. V. Raman
2006-09-24  2:10       ` Richard Stallman
2006-09-24 15:49         ` joakim
2006-09-24 18:00           ` T. V. Raman
2006-09-25  3:17           ` Richard Stallman
2006-09-24 17:58         ` T. V. Raman [this message]
2006-09-25 20:48           ` Richard Stallman
2006-09-27 13:08             ` T. V. Raman
2006-09-28  2:14               ` Richard Stallman
2006-09-23 18:01     ` Richard Stallman
2006-09-26 17:49 ` Andreas Seltenreich
2006-09-27 13:09   ` T. V. Raman
2006-09-27 17:53     ` Andreas Seltenreich
2006-09-28  3:46       ` T. V. Raman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17686.51037.392205.489386@gargle.gargle.HOWL \
    --to=raman@users.sf.net \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    --cc=raman@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.