shugo / ruby-lang.org wrote:
> Eric Wong wrote:
> >  > Could you describe such a race condition in detail?
> >  
> >  	getsockopt(SO_ERROR) => no error
> >  	<kernel sees disconnect>
> >  	read/write => EPIPE, ENOTCONN, ...
> >  
> >  Since we must check all (future) read/write operations for errors
 
> Ah, I see.  However, if getsockopt() returns no error, we can know
> that at least connect() succeeded, right?  I'm not sure whether it's a
> so-called race condition.

I'm not sure if we can know for sure due to implementation differences.
And even if connect() succeeded, the server could decide to disconnect
right away after accept() due to overload, so probably less important.

> >  anyways, getsockopt(SO_ERROR) is worthless.

> I don't think getsockopt(SO_ERROR) is worthless because users can know
> error information sooner and more exactly than subsequent read() or
> write().

The error may be seen sooner, but I think the errors are uncommon
and most users will not care.  They will see any error and handle it
their own way.

> >  Maybe, but I wonder if we can just drop a lot of code...
> >  
> >  	http://bogomips.org/ruby.git/patch?id=a4212dc9516f4
> 
> With the patch, connect() is called again even if getsockopt(SO_ERROR) returns an error, so Errno::EINVAL is raised.  It's confusing behavior.

Ah, I forget the outer for(;;) loop.  Maybe it's better to not loop,
the WAIT_IN_PROGRESS stuff is confusing...