Re: non-blocking connect fails with no pending acceptors

[Neal H. Walfield]

At Tue, 17 May 2005 22:03:13 -0700 (PDT),
Roland McGrath wrote:
> 
> > If a program calls connect on a non-blocking socket with no pending
> > acceptors (i.e. threads calling accept on the listening end of a
> > socket), connect fails with EWOULDBLOCK.
> 
> This is doubly wrong.  When listen has been called and the queue limit not
> reached, then the connection should be established immediately and not wait
> for someone to call accept.

My patch changes pflocal to exhibit this behavior.

>  When the connection cannot be established
> immediately and the socket is nonblocking, connect should return
> EINPROGRESS.  This should happen when the queue limit has been reached.
> (And then the client socket should be in "waiting to connect" state and a
> later connect call should return EALREADY.)

POSIX also says "[t]he implementation may include incomplete
connections in its listen queue. The limits on the number of
incomplete connections and completed connections queued may be
different."  I understand "incomplete connections" as meaning
connection requests which are established asynchronously.  Do you
agree with this interpretation?

Assuming my understanding is correct, if an implementation includes
"incomplete connections" in the listen queue, the only time
connections would be established asynchronously is when the listen
queue is full in which case the implementation would have to return an
error to the user (POSIX doesn't seem to specify what error to return
here).  Alternatively, an implementation could set the queue length of
incomplete connections to zero with the same results.  The patch that
I sent assumes one of these interpretations and returns EWOULDBLOCK
when the queue is full.

I've tested the aforementioned socket program on 3 systems.  On Linux
(2.6.9), it returns EWOULDBLOCK after 11 successful connects.  On
Tru64, socket() fails with EMFILE (too many open files) when creating
the 4094th socket.  On FreeBSD 4.10, the program successfully connects
17 sockets before failing with ECONNREFUSED.  It seems that none of
these systems implement a separate incomplete connection queue.

I don't see any technical advantage in adding an incomplete connection
queue to our implementation.  Internally, it is not useful (i.e. the
Hurd proper does not require it).  Since no one else seems to
implement this behavior, programs don't rely on it.  Moreover,
programs may incorrectly detect EINPROGRESS as a fatal error and
abort.  I'm not suggesting that we support incorrect programs, but I
don't think we should go out of our way to support functionality which
is not even terribly useful.

Do you agree?

Thanks,
Neal