From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/70632 Path: news.gmane.org!not-for-mail From: Stefan Monnier 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 12:38:33 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1283855933 3888 80.91.229.12 (7 Sep 2010 10:38:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Sep 2010 10:38:53 +0000 (UTC) Cc: ding@gnus.org, emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 07 12:38:51 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 1OsvZe-0005aA-7d for ged-emacs-devel@m.gmane.org; Tue, 07 Sep 2010 12:38:46 +0200 Original-Received: from localhost ([127.0.0.1]:52483 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OsvZd-0002FG-Ox for ged-emacs-devel@m.gmane.org; Tue, 07 Sep 2010 06:38:45 -0400 Original-Received: from [140.186.70.92] (port=34469 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OsvZW-0002E3-Dj for emacs-devel@gnu.org; Tue, 07 Sep 2010 06:38:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OsvZV-0007U7-5T for emacs-devel@gnu.org; Tue, 07 Sep 2010 06:38:38 -0400 Original-Received: from impaqm1.telefonica.net ([213.4.138.1]:42352) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OsvZU-0007Tv-U7 for emacs-devel@gnu.org; Tue, 07 Sep 2010 06:38:37 -0400 Original-Received: from IMPmailhost3.adm.correo ([10.20.102.124]) by IMPaqm1.telefonica.net with bizsmtp id 3idy1f02s2h2L9m01meatK; Tue, 07 Sep 2010 12:38:34 +0200 Original-Received: from ceviche.home ([83.61.51.178]) by IMPmailhost3.adm.correo with BIZ IMP id 3meZ1f0023qhCuj1jmeZHV; Tue, 07 Sep 2010 12:38:34 +0200 X-Brightmail-Tracker: AAAAAA== X-TE-authinfo: authemail="monnier$movistar.es" |auth_email="monnier@movistar.es" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitnetc01" Original-Received: by ceviche.home (Postfix, from userid 20848) id 10BCA660D2; Tue, 7 Sep 2010 12:38:33 +0200 (CEST) In-Reply-To: (joakim@verona.se's message of "Tue, 07 Sep 2010 09:08:26 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:129745 gmane.emacs.gnus.general:70632 Archived-At: >>> 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). > 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