>> It had something to do with attempting a nonblocking connect(),
>> which either works differently under Linux

Quite likely; I've found one gratuitously incompatible interface in my
minimal experience with Linux, it wouldn't surprise me if there's
another.

>> or is improperly implemented in the JDK.

Sounds like it from the below.

>> From a ktrace, I think I found the JDK connect()s to the socket,
>> select()s for completion, and then, when the select returns that the
>> connection is complete, calls connect() a second time,

How bizarre.  After doing a connect() and getting EINPROGRESS, I always
thought you should select for write, and when it succeeds do a
getsockopt for SOL_SOCKET/SO_ERROR.  If the value is 0 the connect
worked; otherwise, it's an errno.

I'd expect calling connect() a second time to attempt another
connection if the first one failed, which is inefficient in time and
network resources, not to mention being a really weird thing to do.

> Funny; Pine relies on this behavior of a nonblocking connect (the
> EISCONN return of the second call to connect()) to verify that a
> socket is connected on most OSes.

I daresay it's fine as a way to verify that a socket is connected - a
TCP socket, at least; a UDP socket will behave rather differently.
(Well, okay, read AF_INET/SOCK_STREAM and AF_INET/SOCK_DGRAM instead,
if you want to be pedantic.)  The problem is with the side-effects
involved when the socket _isn't_ connected.  And if you are sure the
socket is connected, why are you making any call at all?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B