Re: [sdl.web@gmail.com: gnus makes emacs lose response]

[Dave Love <fx@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

Richard Stallman <rms@gnu.org> writes:

> Can you still reproduce this problem?

As far as I know it still occurs, but I don't use the development
Emacs since it's too unstable and difficult to get fixed.

> If so, could you send a test case
> (perhaps the same one) again?

It would take me some time to reconstruct as I've forgotten the
details from the time I wasted before.  (I thought I said in the
previous message that I couldn't find the test case.)  This is all I
have archived.  Note that it's come up at least three times before.


[-- Attachment #2: Type: message/rfc822, Size: 1434 bytes --]

From: Dave Love <d.love@dl.ac.uk>
To: emacs-devel@gnu.org
Subject: Re: timer handlers and ^G
Date: 25 Oct 2001 12:31:58 +0100


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.1: Type: text/plain, Size: 1307 bytes --]

From: Dave Love <d.love@dl.ac.uk>
To: emacs-devel@gnu.org
Subject: Re: timer handlers and ^G
Date: 25 Oct 2001 12:31:58 +0100

>>>>> "GM" == Gerd Moellmann <gerd.moellmann@t-online.de> writes:

 GM> We had that on pretest-bug recently.  I think it's not generally
 GM> a good idea, from the perspective of the user, to let C-g
 GM> interrupt functions run from a timer because (a) the user might
 GM> not be aware that such a function is running, and (b) because not
 GM> all such functions can cope with being interrupted.  I suggested
 GM> to Simon Josefson, I believe, to explicitly bind inhibit-quit to
 GM> nil in Gnus if Gnus can cope with that.

The problem with Gnus & al being able to hang Emacs¹ is due to the
timeouts it specifies on process operations not being honoured when
they're run from a timer.  (Normally `accept-process-output' on an
asynchronous article fetch is the culprit, and there is a loop
involving `select'.)

This was reported before, but no-one could find anything wrong with
process.c.  If I remember correctly, it is reproducible by running
from a timer a shell command which waits for a long time without
producing output.

Footnotes:

¹ If you happen to have `gnuserv' running, you can still use `gnudoit'
  to recover with `(top-level)' (?), as I recall.

  Also, the hang occurs under X.  On a tty, if you C-g twice in this
  situation, Emacs offers to auto-save and then abort and dump core.