From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Calling 'select' from emacs_gnutls_pull Date: Sat, 16 Feb 2013 13:38:43 +0200 Message-ID: <83wqu8qyik.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1361014734 9782 80.91.229.3 (16 Feb 2013 11:38:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Feb 2013 11:38:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Teodor Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 16 12:39:16 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U6g6t-0007hG-Ro for ged-emacs-devel@m.gmane.org; Sat, 16 Feb 2013 12:39:15 +0100 Original-Received: from localhost ([::1]:50997 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U6g6Z-0000Lo-Qc for ged-emacs-devel@m.gmane.org; Sat, 16 Feb 2013 06:38:55 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:40462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U6g6X-0000LQ-GZ for emacs-devel@gnu.org; Sat, 16 Feb 2013 06:38:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U6g6U-0003ao-Hd for emacs-devel@gnu.org; Sat, 16 Feb 2013 06:38:53 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:53029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U6g6U-0003aI-31 for emacs-devel@gnu.org; Sat, 16 Feb 2013 06:38:50 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MIB00M009IT2800@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sat, 16 Feb 2013 13:38:47 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MIB00L289OHX0B0@a-mtaout23.012.net.il>; Sat, 16 Feb 2013 13:38:41 +0200 (IST) X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Error: Can't connect to API socket. X-Received-From: 80.179.55.175 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:157077 Archived-At: Ted, I need your help in understanding the implementation of emacs_gnutls_pull. Specifically, why does it need to call 'select' when 'sys_read' returns EWOULDBLOCK? The file descriptor should already be watched by the call to 'select' in 'wait_reading_process_output', so it seems like a call to 'sys_read' is all that's needed here. Am I missing something? The reason I ask is that someone reported seeing these messages when running Emacs on Windows under a debugger: warning: sys_read called when read is in progress This comes from 'sys_read', and it means that the reader thread (used by Emacs to read from a socket) is already blocked inside a call to 'recv' on behalf of this file descriptor, when 'sys_read' is called. I think that the sequence of events which leads to this is as follows: . emacs_gnutls_pull calls sys_read, which returns EWOULDBLOCK, because there's no data ready to be read . emacs_gnutls_pull then calls select, which wakes up the reader thread and tells it to try reading from the socket . the reader thread blocks inside the call to recv (since no data is ready) . the call to select times out and returns EWOULDBLOCK, which causes emacs_gnutls_pull to break from the loop and return EAGAIN . after some time, emacs_gnutls_pull is called again, and calls sys_read while the reader thread is still blocked in recv, so we get the above message Is this a plausible description of what might happen? If so, would it make sense to avoid calling 'select' in emacs_gnutls_pull, and instead let 'wait_reading_process_output' call 'select', as it does for all the other sockets open in Emacs? Or am I missing something? TIA