This is the mail archive of the mauve-discuss@sourceware.org mailing list for the Mauve project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]