This is the mail archive of the
mailing list for the Mauve project.
Re: New SocketChannel test that requires testing
Jeroen Frijters wrote:
> 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.
"If this channel is in non-blocking mode then an invocation of this
method initiates a non-blocking connection operation. If the connection
is established immediately, as can happen with a local connection, then
this method returns true. Otherwise this method returns false and the
connection operation must later be completed by invoking the
finishConnect method."