unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: joakim@verona.se
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: ding@gnus.org, emacs-devel@gnu.org
Subject: Re: Blocking call to accept-process-output with quit inhibited!! [11 times]
Date: Tue, 07 Sep 2010 13:11:14 +0200	[thread overview]
Message-ID: <m3y6bderl9.fsf@verona.se> (raw)
In-Reply-To: <jwvmxrtdeox.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Tue, 07 Sep 2010 12:38:33 +0200")

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> In Emacs 24, I get this message the first time I enter a Gnus group.
>>>> What does it mean, and what can I do to make it go away?
>>> It means just that: accept-process-output is called in a way that can
>>> block (e.g. because some remote host doesn't respond) wit inhibit0quit
>>> set to a non-nil value, which means that Emacs may end up frozen (with
>>> no way to wake it up) for as long as the remote machine decides not
>>> to answer.
>>> IOW, maybe there should be a (with-local-quit ...) somewhere so that the
>>> user can C-g out of such a state (or the call should have a timeout, or
>>> inhibit-quit should not be set, ...).
>
>> I get bitten by this quite a lot, since I'm often on a flaky 3g
>> line. When the link goes down, and some Emacs socket is still up, Emacs
>> freezes. This is quite annoying.
>
> Emacs should not freeze in such a case.  IIUC most cases where this
> happen are Elisp bugs (typically a missing with-local-quit or something
> like that), tho there are a few cases where it's a problem at the
> C level (IIRC, one such is during hostname lookup, but I don't know of
> any such case once the TCP connection is established).

But why then is quit inhibited at all?

Anyway, the freeze is quite easily reproducible. (as have been described in some
old bug reports)

- start gnus, make sure you read some nntp groups so nntp sockets are
  open
- make your network interface go away somehow (disconnecting 3g or
  something, but simply ifconfiging away should also work)
- stare in horror as your emacs freezes

This particular problem happens to me so often I have written a
workaround script like this:

,----
| #/bin/sh
| `lsof -n|grep emacs|grep nntp|sed "s/.*TCP\ \\([^:]*\\):.*->\\([^:].*\\):.*/  export a=\\1 export b=\\2/"`
| echo $a $b
| ifconfig eth2:1 $a
| ifconfig eth2:2 $b
| echo press enter when emacs is alive
| read
| ifconfig eth2:1 down
| ifconfig eth2:2 down
`----

since the socket is left even though the interface is gone, the script
ifconfigs new interfaces with information gleaned from the hanging
socket. After a while Emacs will live again, and the interfaces can be
removed.

>> I suppose that the hard blocking is there to prevent data loss or
>> whatever, but having to kill -9 Emacs results in worse dataloss.
>
> No, usually it's there because the Elisp coder is not aware of the risk
> (e.g. he doesn't realize his code will be run with inhibit-quit set,
> probably because he doesn't realize that this is set whenever we run
> process filters, process sentinels, post-command-hook, jit-lock,
> timers, and a handful other cases).
>
>
>         Stefan

-- 
Joakim Verona



  reply	other threads:[~2010-09-07 11:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-06 21:23 Blocking call to accept-process-output with quit inhibited!! [11 times] Lars Magne Ingebrigtsen
2010-09-06 21:41 ` Stefan Monnier
2010-09-06 21:48   ` Lars Magne Ingebrigtsen
2010-09-07  7:08   ` joakim
2010-09-07 10:38     ` Stefan Monnier
2010-09-07 11:11       ` joakim [this message]
2010-09-07 11:53         ` Lars Magne Ingebrigtsen
2010-09-07 13:25           ` joakim
2010-09-07 16:30             ` Lars Magne Ingebrigtsen
2010-09-08  8:10         ` Stefan Monnier
2010-09-07 18:33       ` Tom Tromey
2010-09-08  8:12         ` Stefan Monnier
2010-09-07 11:54   ` Lars Magne Ingebrigtsen
2010-09-08  8:15     ` Stefan Monnier
2010-09-08 16:29       ` Lars Magne Ingebrigtsen
2010-09-08 18:54         ` Andreas Schwab
2010-09-08 18:56           ` Lars Magne Ingebrigtsen
2010-09-08 22:54             ` Stefan Monnier
2010-09-08 23:29               ` Lars Magne Ingebrigtsen
2010-09-17  0:36                 ` Lars Magne Ingebrigtsen
2010-09-17 15:43                   ` Stefan Monnier

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=m3y6bderl9.fsf@verona.se \
    --to=joakim@verona.se \
    --cc=ding@gnus.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).