[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: non-blocking connect fails with no pending acceptors
From: |
Neal H. Walfield |
Subject: |
Re: non-blocking connect fails with no pending acceptors |
Date: |
Wed, 18 May 2005 11:20:22 +0100 |
User-agent: |
Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Tue, 17 May 2005 19:05:52 -0700,
Thomas Bushnell BSG wrote:
>
> "Neal H. Walfield" <neal@walfield.org> 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