[Top] [All Lists]

Re: [PATCH] connect() return value.

To: kuznet@xxxxxxxxxxxxx
Subject: Re: [PATCH] connect() return value.
From: Geoffrey Lee <glee@xxxxxxxxxxxxxxx>
Date: Wed, 14 Aug 2002 14:57:55 +1000
Cc: netdev@xxxxxxxxxxx
In-reply-to: <200208140416.IAA23134@xxxxxxxxxxxxx>
References: <20020814030242.GA30872@xxxxxxxxxxxxxxxx> <200208140416.IAA23134@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mutt/1.4i
> Because any error but EAGAIN/EINTR is failure. As you convinced

Yep. I thought about this as well.

If you used read with a byte count of 0 / 1, and it returned -1 to
the program with errno set to ENOTCONN, you cannot be confident whether
it is trying to complete a 3 way handshake or the connection failed.

> yourself there is no good way to detect connection completion,
> so in fact writing correct program is next to impossible.

I am a bit jaded about non-blocking connects on Unix, because is even
more non-portable than I ever imagined.

> Actually, never in my life I have seen a pattern of program
> with waits for EISCONN after EINTR on connect() (but lots of them
> fail when not seeing 0), so I have no idea why they work under these OSes.
> Apparently, they fail randomly.


On Solaris / Digital UNIX the 3 way handshake completes asynchronously
on EINTR. Checking for a EISCONN is one non-perfect solution to check
for a successful connection establishment.

So, in the near future, we can expect Linux to not return 0 for
non-blocking connects (i.e. the change you mentioned)?

        -- G.

<Prev in Thread] Current Thread [Next in Thread>