This is the mail archive of the
mauve-discuss@sourceware.org
mailing list for the Mauve project.
RE: New SocketChannel test that requires testing
- From: "Jeroen Frijters" <jeroen at sumatra dot nl>
- To: "Casey Marshall" <csm at gnu dot org>
- Cc: <mauve-discuss at sourceware dot org>
- Date: Tue, 19 Sep 2006 07:31:58 +0200
- Subject: RE: New SocketChannel test that requires testing
Casey Marshall wrote:
> 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
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
> 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.
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