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

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

[Richard Stallman]

Would someone please take a look?

------- Start of forwarded message -------
To: emacs-pretest-bug@gnu.org
From: Leon <sdl.web@gmail.com>
Date: Wed, 29 Mar 2006 03:44:12 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: gnus makes emacs lose response
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

Dear all,

If I am using gnus and disconnect the network cable, after a while
emacs will lose response. C-g won't work. I have to `killall emacs'. I
think this is due to demon trying to fetch news/emails.

My setting of demon in gnus:
- --8<---------------cut here---------------start------------->8---
;; fetch email while idle
(gnus-demon-add-handler 'gnus-group-get-new-news 3 t)
(gnus-demon-init)
- --8<---------------cut here---------------end--------------->8---

Regards,
- -- 
Leon



_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

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

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> Would someone please take a look?
>
> ------- Start of forwarded message -------
> To: emacs-pretest-bug@gnu.org
> From: Leon <sdl.web@gmail.com>
> Date: Wed, 29 Mar 2006 03:44:12 +0100
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Subject: gnus makes emacs lose response
> X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
> 	version=3.0.4
>
> Dear all,
>
> If I am using gnus and disconnect the network cable, after a while
> emacs will lose response. C-g won't work. I have to `killall emacs'. I
> think this is due to demon trying to fetch news/emails.

This is a longstanding problem with background processes.  I sent a
test case maybe two years ago, but as far as I know it never got fixed
and I couldn't follow the process code to fix it confidently.  I can't
find the test case, but I seem to remember it involved the timeout on
`accept-process-output' not being obeyed.

If you're on a tty, C-g in this state stops Emacs and gives you the
`abort or auto-save' question.  Non-keyboard input is still processed,
so that you can get out of it by invoking `top-level' with the
`gnudoit' program or having bound that to a user signal and sending
the signal.

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

[Richard Stallman]

    This is a longstanding problem with background processes.  I sent a
    test case maybe two years ago, but as far as I know it never got fixed
    and I couldn't follow the process code to fix it confidently.

Can you still reproduce this problem?  If so, could you send a test case
(perhaps the same one) again?

Re: gnus makes emacs lose response

[Reiner Steib]

On Thu, Apr 06 2006, Richard Stallman wrote:

>     This is a longstanding problem with background processes.  I sent a
>     test case maybe two years ago, but as far as I know it never got fixed
>     and I couldn't follow the process code to fix it confidently.
>
> Can you still reproduce this problem?  If so, could you send a test case
> (perhaps the same one) again?

On emacs-devel, Kim F. Storm wrote:

| I installed a fix to the CVS trunk (22.x) on 2006-03-22 that may have
| fixed this problem (it corrected an rather severe issue with the
| timeout of accept-process-output).

Leon, the OP, wrote that it's not fixed for him yet.  But he uses the
unicode branch (Emacs/23.0) which might not contain Kim's patch yet.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

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

[Richard Stallman]

I hope someone will find this bug, some day or other.

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

[Dave Love]

[-- 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.