From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/63767 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: gnus makes emacs lose response Date: Sat, 23 Sep 2006 18:42:07 -0500 (CDT) Message-ID: <200609232342.k8NNg7pL007121@jane.dms.auburn.edu> References: <8764fe4fb9.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1159054952 16881 80.91.229.2 (23 Sep 2006 23:42:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 23 Sep 2006 23:42:32 +0000 (UTC) Cc: ding@gnus.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 24 01:42:30 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GRH8f-000544-3S for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2006 01:42:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRH8e-0006NX-5m for ged-emacs-devel@m.gmane.org; Sat, 23 Sep 2006 19:42:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GRH8R-0006N8-6Q for emacs-devel@gnu.org; Sat, 23 Sep 2006 19:42:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GRH8P-0006Mt-DR for emacs-devel@gnu.org; Sat, 23 Sep 2006 19:42:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRH8P-0006Mq-9z for emacs-devel@gnu.org; Sat, 23 Sep 2006 19:42:13 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1GRHCT-0005f1-60 for emacs-devel@gnu.org; Sat, 23 Sep 2006 19:46:25 -0400 Original-Received: from jane.dms.auburn.edu (jane.dms.auburn.edu [131.204.53.201]) by manatee.dms.auburn.edu (8.13.7+Sun/8.13.7) with ESMTP id k8NNgBx6027160; Sat, 23 Sep 2006 18:42:11 -0500 (CDT) Original-Received: from jane.dms.auburn.edu (localhost [127.0.0.1]) by jane.dms.auburn.edu (8.13.4+Sun/8.13.4) with ESMTP id k8NNg7l9007124; Sat, 23 Sep 2006 18:42:07 -0500 (CDT) Original-Received: (from teirllm@localhost) by jane.dms.auburn.edu (8.13.4+Sun/8.13.3/Submit) id k8NNg7pL007121; Sat, 23 Sep 2006 18:42:07 -0500 (CDT) X-Authentication-Warning: jane.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: cyd@stupidchicken.com In-reply-to: <8764fe4fb9.fsf@stupidchicken.com> (message from Chong Yidong on Sat, 23 Sep 2006 14:18:34 -0400) 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:60153 gmane.emacs.gnus.general:63767 Archived-At: Chong Yidong wrote: After some further communication with Leon, I think I know the problem: accept-process-output is called by the timer function `gnus-demon' (which is a valid but IIUC not commonly-used component of Gnus). However, as documented in the Lisp Reference manual: Emacs binds `inhibit-quit' to `t' before calling the timer function, because quitting out of many timer functions can leave things in an inconsistent state. This is normally unproblematical because most timer functions don't do a lot of work. Indeed, for a timer to call a function that takes substantial time to run is likely to be annoying. The result in this case is that this accept-process-output can't be interrupted, and Emacs can hang if the process doesn't reply (e.g., if the connection dies). I'm not sure what the best way to handle this is. Anyone? I have no time to look at the actual code, but is there any reason why the routine way to handle this problem, namely using `with-local-quit' (see (elisp)Quitting) around the problematic code (in this case probably the call to accept-process-output) does not work in this case? Sincerely, Luc.