[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Did something change with respect to Emacs idle loop:
From: |
T. V. Raman |
Subject: |
Re: Did something change with respect to Emacs idle loop: |
Date: |
Sun, 24 Sep 2006 10:58:53 -0700 |
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 <address@hidden> 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: address@hidden
WWW: http://emacspeak.sf.net/raman/
AIM: emacspeak GTalk: address@hidden
PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman
IRC: irc://irc.freenode.net/#emacs
- Re: Did something change with respect to Emacs idle loop:, (continued)
Re: Did something change with respect to Emacs idle loop:, Richard Stallman, 2006/09/22
- Re: Did something change with respect to Emacs idle loop:, Chong Yidong, 2006/09/22
- Re: Did something change with respect to Emacs idle loop:, T. V. Raman, 2006/09/23
- Re: Did something change with respect to Emacs idle loop:, Richard Stallman, 2006/09/23
- Re: Did something change with respect to Emacs idle loop:, joakim, 2006/09/24
- Re: Did something change with respect to Emacs idle loop:, T. V. Raman, 2006/09/24
- Re: Did something change with respect to Emacs idle loop:, Richard Stallman, 2006/09/24
- Re: Did something change with respect to Emacs idle loop:,
T. V. Raman <=
- Re: Did something change with respect to Emacs idle loop:, Richard Stallman, 2006/09/25
- Re: Did something change with respect to Emacs idle loop:, T. V. Raman, 2006/09/27
- Re: Did something change with respect to Emacs idle loop:, Richard Stallman, 2006/09/27
Re: Did something change with respect to Emacs idle loop:, Richard Stallman, 2006/09/23
Re: Did something change with respect to Emacs idle loop:, Andreas Seltenreich, 2006/09/26