From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27328 invoked by alias); 19 Sep 2006 08:08:54 -0000 Received: (qmail 27319 invoked by uid 22791); 19 Sep 2006 08:08:53 -0000 X-Spam-Check-By: sourceware.org Received: from mail.cruzio.com (HELO mail.cruzio.com) (63.249.95.37) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Sep 2006 08:08:51 +0000 Received: from [192.168.0.200] (c-67-169-118-183.hsd1.ca.comcast.net [67.169.118.183]) by mail.cruzio.com with ESMTP id k8J88mcC039479; Tue, 19 Sep 2006 01:08:48 -0700 (PDT) Message-ID: <450FA587.8070707@gnu.org> Date: Tue, 19 Sep 2006 08:08:00 -0000 From: Casey Marshall User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Jeroen Frijters CC: mauve-discuss@sourceware.org Subject: Re: New SocketChannel test that requires testing References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact mauve-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sourceware.org X-SW-Source: 2006-q3/txt/msg00028.txt.bz2 Jeroen Frijters wrote: > Casey Marshall wrote: >> Maybe we are wrong for returning true for `isConnected' that >> early after trying to establish the connection; the test we're using >> is whether or not the socket has a remote address or not, which may >> not be the criteria we're interested in. > > Yes, I believe that's incorrect. I think you can only transition into > the connected state by calling finishConnect (if connect was called in > non-blocking mode). > That's not necessarily true; on some systems, even a non-blocking call to connect() can succeed immediately, if you are connecting to the local machine. It doesn't sound right that you get this condition even when the server process hasn't pulled the connection off the queue, but that may be how it works. I wonder, now, if this is an artifact of our (new) RI: we call a nonblocking connect() every time, then select() on the server's FD to handle the blocking case, with timeout. This may be doing the wrong thing with nonblocking sockets. Thanks.