Patch: fix non-blocking socket connect

[Tom Tromey]

>>>>> "Anthony" == Anthony Green <green@redhat.com> writes:

Anthony> Incorrect?  Really?

Thanks for the pointer to SocketChannelImpl.
This stuff is even messier than I thought.

There seems to be two cases here.  One is a plain call to
connect-with-timeout, made on a java.net.SocketImpl instance.  I think
my previous comments apply to this case -- though it isn't 100% clear
what should happen to the socket here if the connect times out.

Anthony> Note that it's SocketChannel.connect() that returns early, but it does
Anthony> this by calling SocketImpl.connect() with a short timeout value (50),
Anthony> catching the timeout exception, and then checking for the fd in
Anthony> Selector.select() since we did the  original connect in non-blocking
Anthony> mode.

Yeah, for this case I think your patch is right.  I still don't like
how this code works though.  I suppose at the very least we need a PR
for the oddities... also it looks like the nio code tries to inform
the net code that it is doing a channel-based operation, but then
this information doesn't appear to be used by the net code at all.
Weird.

Could you file a PR for some of the weird things here?  And add a
comment to your patch explaining why we set the fields where we do?


I wonder if SocketChannelImpl.finalizer() is misnamed.  The
implementation looks weird too.  Ugh.

Tom