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

Reply via email to