Re: New SocketChannel test that requires testing

[Casey Marshall <csm at gnu dot org>]

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.