From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27760 invoked by alias); 19 Sep 2006 05:32:06 -0000 Received: (qmail 27752 invoked by uid 22791); 19 Sep 2006 05:32:05 -0000 X-Spam-Check-By: sourceware.org Received: from 62-177-154-238.dsl.bbeyond.nl (HELO lembu.sumatrasoftware.com) (62.177.154.238) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Sep 2006 05:32:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New SocketChannel test that requires testing Date: Tue, 19 Sep 2006 05:32:00 -0000 Message-ID: In-Reply-To: <450F2199.9010501@gnu.org> From: "Jeroen Frijters" To: "Casey Marshall" Cc: X-IsSubscribed: yes 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/msg00027.txt.bz2 Casey Marshall wrote: > Jeroen Frijters wrote: > > Hi, > >=20 > > 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. > >=20 > > 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=20 > connection to make > > sure that a subsequent connection attempt will block (to test if > > asynchronous connections work correctly). > >=20 > > I tested this on Windows (JDK 1.5 and IKVM) and I would=20 > appreciate it if > > people would run this test on their platform of choice.=20 > Other feedback > > on the validity of this approach is also appreciated. > >=20 >=20 > It doesn't quite work for me (jamvm+classpath CVS and java=20 > 1.5; both on > OSX/x86). I get two fails with classpath: >=20 > FAIL: java.nio.channels.SocketChannel.tests > line 65: initiate async connect [2] -- boolean passed to=20 > check was false > line 67: initiate async connect [4] -- boolean passed to=20 > check was false >=20 > And one with Sun/Apple Java: >=20 > FAIL: java.nio.channels.SocketChannel.tests > line 67: initiate async connect [4] -- boolean passed to=20 > check was false Hmm, that's unfortunate. I don't know of any other way to reliably build a test for these things. Thanks for testing this. > I think this is because that connect is, indeed, eating up a=20 > 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. >=20 > Maybe we are wrong for returning true for `isConnected' that=20 > 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). Regards, Jeroen