Re: [PATCH] connect() return value.

[Geoffrey Lee <glee@xxxxxxxxxxxxxxx>]

On Tue, Aug 13, 2002 at 05:47:14PM +0400, kuznet@xxxxxxxxxxxxx wrote:
> Hello!
> 
> > Ah, yes you're right. I was feeling stupid and I forgot to clear the
> > errno because re-trying the connect().
> 
> Good. :-)
> 
> Could you repeat corrected test with repreated nonblocking connect()
> on those OSes?
> 

Alright, it looks like I've been smoking too much pot. I'm going to post
the source code [ugly] here as well so what you see is what you get (no more
oops-I-forgot-to-clear-errno oddities again :-)


Let's redo the experiment from the start:

This is the following OS I will test against:

SunOS 5.6
OSF1 4.0
Linux v2.4.18

Source files:
connect.c
connect3.c

connect.c tests for interruptibility with a particular OS.
connect3.c tests for what connect returns if the socket is set 
into non-blocking mode.


First off, we note the behavior of the with regard to interruptibility 
of connect. I use SIGALRM, sigaction with SA_RESTART, and connect to a 
valid IP where the host is down / no host is present. Default blocking
behavior.

SunOS 5.6:

sighandler called, connect fails with -EINTR


OSF1 4.0

sighandler called, connect fails with -EINTR

(I have no idea why I "corrected" myself before that it's restartable,
possibly some cruft I left behind with a read() following connect. So
a return of -EINTR is my Final Answer. Sorry for that confusion.)

Linux 2.4.18:

sighandler is called, but we see that the program does not exit, this
seems to imply that the connect is restarted.


Now, we try with no signals, connect to a valid IP where host is up with
a valid port listening. We use fcntl() to set the socket to
non-blocking mode.



SunOS 5.6

-EINPROGRESS, -EALREADY, -EISCONN, in that order.


OSF1 4.0


-EINPROGRESS, -EALREADY, -EISCONN in that order.



Linux 2.4.18

-EINPROGRESS, -EALREADY, 0 (Success), -EISCONN, in that order.


So Linux does indeed return 0, and this is the magic value that
we are looking for. People writing portably will be required to
handle 0 in Linux, as well as possibly an error of -EISCONN (this
error is ok and seems to be expected in OSF1 4.0 and SunOS 5.6).




        -- G.

connect.c
Description: Text Data

connect3.c
Description: Text Data