From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: Blocking call to accept-process-output with quit inhibited!! [11 times] Date: Tue, 07 Sep 2010 13:11:14 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1283858508 14559 80.91.229.12 (7 Sep 2010 11:21:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Sep 2010 11:21:48 +0000 (UTC) Cc: ding@gnus.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 07 13:21:45 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OswFD-0002KY-Tz for ged-emacs-devel@m.gmane.org; Tue, 07 Sep 2010 13:21:44 +0200 Original-Received: from localhost ([127.0.0.1]:35146 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OswFC-0005AQ-Oh for ged-emacs-devel@m.gmane.org; Tue, 07 Sep 2010 07:21:42 -0400 Original-Received: from [140.186.70.92] (port=36621 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OswEy-0004ww-5e for emacs-devel@gnu.org; Tue, 07 Sep 2010 07:21:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Osw59-0005pf-2E for emacs-devel@gnu.org; Tue, 07 Sep 2010 07:11:20 -0400 Original-Received: from smtprelay-b12.telenor.se ([62.127.194.21]:51578) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Osw58-0005pQ-KX for emacs-devel@gnu.org; Tue, 07 Sep 2010 07:11:19 -0400 Original-Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-b12.telenor.se (Postfix) with ESMTP id E717BE99F9 for ; Tue, 7 Sep 2010 13:11:16 +0200 (CEST) X-SENDER-IP: [83.227.138.150] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUxACq6hUxT44qWPGdsb2JhbACHapkGDAEBAQE1Lb0OhT0EihiDDg X-IronPort-AV: E=Sophos;i="4.56,328,1280700000"; d="scan'208";a="127658958" Original-Received: from ua-83-227-138-150.cust.bredbandsbolaget.se (HELO www.verona.se) ([83.227.138.150]) by ipb1.telenor.se with ESMTP; 07 Sep 2010 13:11:16 +0200 Original-Received: from localhost.localdomain (unknown [192.168.201.6]) by www.verona.se (Postfix) with ESMTP id EEB7C7303C6; Tue, 7 Sep 2010 13:11:14 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Tue, 07 Sep 2010 12:38:33 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:129746 gmane.emacs.gnus.general:70633 Archived-At: Stefan Monnier 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