Re: Did something change with respect to Emacs idle loop:

[joakim@verona.se]

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