From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Reviving Gnus after suspend/hibernation Date: Fri, 28 Oct 2011 20:50:24 -0400 Message-ID: References: <87wrc2qmog.fsf@gnu.org> <877h3ule0y.fsf@lifelogs.com> <87hb2ucox4.fsf@lifelogs.com> <83lis6b8t9.fsf@gnu.org> <8762jajn5q.fsf@lifelogs.com> <87ehxym87k.fsf@lifelogs.com> <87mxckx3hx.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1319849435 17241 80.91.229.12 (29 Oct 2011 00:50:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 29 Oct 2011 00:50:35 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 29 02:50:31 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RJx82-0008Gi-2Q for ged-emacs-devel@m.gmane.org; Sat, 29 Oct 2011 02:50:30 +0200 Original-Received: from localhost ([::1]:54730 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJx81-0008QQ-BZ for ged-emacs-devel@m.gmane.org; Fri, 28 Oct 2011 20:50:29 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJx7y-0008QL-Ul for emacs-devel@gnu.org; Fri, 28 Oct 2011 20:50:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RJx7x-0005kC-NF for emacs-devel@gnu.org; Fri, 28 Oct 2011 20:50:26 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:47977 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJx7x-0005k6-Kh for emacs-devel@gnu.org; Fri, 28 Oct 2011 20:50:25 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUGAJdNq05MCrTo/2dsb2JhbABCmlePDoEGgXIBAQQBVjMLNBIUGA2IObQKiQMEoUSERQ X-IronPort-AV: E=Sophos;i="4.69,421,1315195200"; d="scan'208";a="145016556" Original-Received: from 76-10-180-232.dsl.teksavvy.com (HELO pastel.home) ([76.10.180.232]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 28 Oct 2011 20:50:24 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 266F558E26; Fri, 28 Oct 2011 20:50:24 -0400 (EDT) In-Reply-To: <87mxckx3hx.fsf@lifelogs.com> (Ted Zlatanov's message of "Fri, 28 Oct 2011 16:31:06 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:145731 Archived-At: >>> You're right, but on suspend&resume we should not have to wait for the >>> TCP connection to time out. Let's assume it's closed in that specific >>> case and set the keepalive for general use. SM> It strikes me as a non-Emacs-specific problem, so maybe the OS should SM> kill its TCP connection between suspend and resume. > It probably does. The Linux kernel definitely does not (and barring a NAT router, or a resume with a different IP, or attempted communication on the link while you're sleeping, the TCP connection will be faithfully waiting for us when we resume). >>> Is this just a GnuTLS problem? Does any of the rest of Emacs have >>> issues with hung connections? SM> I've been suffering from it for many years. I'm not sure if it SM> affects NNTP connections (it probably does) but it for sure affects SM> nnimap with gnutls-cli. > That's a completely different use case, you're wrapping a process with > arbitrary output when you use gnutls-cli. I'd prefer to work just on > hung TCP connections. There are different cases at play indeed: gnutls-cli is one, NNTP (without TLS) is another, and nnimap with libgnutls is yet another. I think I see similar problems in all three cases, caused by the same underlying OS-level problem. But since the C and Elisp code that wraps it is different, the exact behavior will differ (e.g. typically w.r.t reaction to C-g, possibility of a timeout, ...). Stefan