This is the mail archive of the
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 10:21:05 +0200
- Subject: RE: New SocketChannel test that requires testing
Casey Marshall wrote:
> Jeroen Frijters wrote:
> > Casey Marshall wrote:
> >> 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).
> That's not necessarily true; on some systems, even a non-blocking call
> to connect() can succeed immediately, if you are connecting
> to the local machine. It doesn't sound right that you get this
> condition even when the server process hasn't pulled the connection
> off the queue, but that may be how it works.
I don't think it has nothing to do with the underlying socket mechanics,
it is simply an invariant of the SocketChannel API.