From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2480 invoked by alias); 18 Sep 2006 22:45:52 -0000 Received: (qmail 2471 invoked by uid 22791); 18 Sep 2006 22:45:52 -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; Mon, 18 Sep 2006 22:45:50 +0000 Received: from [172.100.25.3] (unknown.Level3.net [64.154.219.132] (may be forged)) by mail.cruzio.com with ESMTP id k8IMjmsN030619; Mon, 18 Sep 2006 15:45:49 -0700 (PDT) Message-ID: <450F2199.9010501@gnu.org> Date: Mon, 18 Sep 2006 22:45: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/msg00026.txt.bz2 Jeroen Frijters wrote: > Hi, > > I've written a new test case for SocketChannel and I require some > assistance testing it on different platforms (and/or opinions on it) > because it uses a trick and I would like to know if the trick is > reliable or not. > > The trick is that it creates a server socket with a backlog of 1 and > then it fills up that backlog queue by initiating a connection to make > sure that a subsequent connection attempt will block (to test if > asynchronous connections work correctly). > > I tested this on Windows (JDK 1.5 and IKVM) and I would appreciate it if > people would run this test on their platform of choice. Other feedback > on the validity of this approach is also appreciated. > It doesn't quite work for me (jamvm+classpath CVS and java 1.5; both on OSX/x86). I get two fails with classpath: FAIL: java.nio.channels.SocketChannel.tests line 65: initiate async connect [2] -- boolean passed to check was false line 67: initiate async connect [4] -- boolean passed to check was false And one with Sun/Apple Java: FAIL: java.nio.channels.SocketChannel.tests line 67: initiate async connect [4] -- boolean passed to check was false I think this is because that connect is, indeed, eating up a slot in the backlog, but the kernel allowed the connection anyway. So as far as the client SocketChannel is concerned, it's connected, and the socket is writable. 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.