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 _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
