At Tue, 17 May 2005 19:05:52 -0700, Thomas Bushnell BSG wrote: > > "Neal H. Walfield" <[EMAIL PROTECTED]> writes: > > > 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. It is unclear to me if this > > behavior is POSIX-conforming or not [1], however, (1) there are programs > > which do not expect this behavior; and (2) connect on other systems > > does not block before the number of connects without a accept exceeds > > the listen queue length (we treat the queue length as the maximum > > number of threads which can block doing a connect). > > You think the behavior should be to allow the connect to succeed > immediately?
I guess that is one way to interpret it. The socket interface is not a topic that I am very interested: it seems adequate; my end was only to make the Hurd more POSIX compliant and what I proposed is an attempt to do this. If you want to support some non-POSIX behavior as an extension, I don't see any reason we couldn't do that. I think that we shouldn't do that, however, unless the interfaces actually solve a specific problem which we are able to articulate. I don't see the current interface as having any technical advantages over what POSIX requires. In fact, it only creates problems: programs rely no POSIX. Since nothing relies on the old behavior, I see no reason to retain it. > Ok, that's fine, but what then happens when you try to > move data... should it block, waiting for the connection to actually > be made? I don't understand. The connection is "actually" made when you call connect. POSIX says[1]: If the initiating socket is connection-mode, then connect() shall attempt to establish a connection to the address specified by the address argument. If the connection cannot be established immediately and O_NONBLOCK is not set for the file descriptor for the socket, connect() shall block As I understand it, if connect succeeds, the connection has "actually" been made. This is what my patch does. Thanks, Neal [1] http://www.opengroup.org/onlinepubs/009695399/functions/connect.html _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd