From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: gnutls error handling Date: Sun, 17 Oct 2010 18:21:14 +0200 Message-ID: <4CBB227A.6010004@swipnet.se> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1287332753 26242 80.91.229.12 (17 Oct 2010 16:25:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 17 Oct 2010 16:25:53 +0000 (UTC) Cc: Lars Magne Ingebrigtsen , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 17 18:25:52 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 1P7W3T-0004jL-C9 for ged-emacs-devel@m.gmane.org; Sun, 17 Oct 2010 18:25:51 +0200 Original-Received: from localhost ([127.0.0.1]:48683 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P7W3R-0005sJ-FP for ged-emacs-devel@m.gmane.org; Sun, 17 Oct 2010 12:25:49 -0400 Original-Received: from [140.186.70.92] (port=43866 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P7W3A-0005ju-07 for emacs-devel@gnu.org; Sun, 17 Oct 2010 12:25:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P7VzL-0003HU-KM for emacs-devel@gnu.org; Sun, 17 Oct 2010 12:21:36 -0400 Original-Received: from smtprelay-h32.telenor.se ([213.150.131.5]:48204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P7VzG-0003GS-62; Sun, 17 Oct 2010 12:21:30 -0400 Original-Received: from ipb1.telenor.se (ipb1.telenor.se [195.54.127.164]) by smtprelay-h32.telenor.se (Postfix) with ESMTP id E6F94EB70E; Sun, 17 Oct 2010 18:21:25 +0200 (CEST) X-SENDER-IP: [85.225.45.100] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloxAA+/ukxV4S1kPGdsb2JhbACHcZk5DAEBAQE1LcMehUkEjU8 X-IronPort-AV: E=Sophos;i="4.57,342,1283724000"; d="scan'208";a="142137139" Original-Received: from c-642de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.100]) by ipb1.telenor.se with ESMTP; 17 Oct 2010 18:21:25 +0200 Original-Received: from [172.20.199.2] (gaffa [172.20.199.2]) by coolsville.localdomain (Postfix) with ESMTPSA id 01DA57FA05A; Sun, 17 Oct 2010 18:21:24 +0200 (CEST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 In-Reply-To: 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:131781 Archived-At: Eli Zaretskii skrev 2010-10-17 17:22: >> From: Lars Magne Ingebrigtsen >> Date: Sun, 17 Oct 2010 15:55:24 +0200 >> Mail-Copies-To: never >> >> poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0 (Timeout) >> select(15, [3 4 8 10 13], [], NULL, {0, 15591}) = 2 (in [8 10], left {0, 15589}) >> read(3, 0xec9b94, 4096) = -1 EAGAIN (Resource temporarily unavailable) >> poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0 (Timeout) >> select(15, [3 4 8 10 13], [], NULL, {0, 15532}) = 2 (in [8 10], left {0, 15530}) >> read(3, 0xec9b94, 4096) = -1 EAGAIN (Resource temporarily unavailable) >> >> There's always a gnutls socket involved in the select call -- in this >> instance it was fd 10. lsof showed the socket to be in the CLOSE_WAIT >> state. So my suspicion is that the we're somehow now communicating back >> to Emacs that a gnutls socket has closed. > Not really a useful answer, but the `select' man page has this piece > of wisdom: > > Under Linux, select() may report a socket file descriptor as > "ready for reading", while nevertheless a subsequent read > blocks. This could for example happen when data has arrived > but upon examination has wrong checksum and is discarded. > There may be other circumstances in which a file descriptor is > spuriously reported as ready. Thus it may be safer to use > O_NONBLOCK on sockets that should not block. > > Of course, we already use O_NONBLOCK (AFAIK). The question is why is Emacs reading fd 3? It is not reported as ready by select, fd 8 and 10 are ready, but those aren't read. Jan D.