ruby-core

Issue #9356 has been updated by Shugo Maeda.


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.

>  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().

>  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.


----------------------------------------
Bug #9356: TCPSocket.new does not seem to handle INTR
https://bugs.ruby-lang.org/issues/9356#change-45275

* Author: Charlie Somerville
* Status: Open
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* ruby -v: -
* Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
TCPSocket.new does not seem to handle EINTR properly.

In the attached test script, I try to open a TCP connection to my server and make an HTTP request while a background thread continually sends a signal to the process.

This causes the #write call to fail with:

x.rb:13:in `write': Socket is not connected (Errno::ENOTCONN)
	from x.rb:13:in `<main>'

This also appears to affect 2.0.0. 1.9.3 is unaffected.

---Files--------------------------------
socket-eintr.rb (207 Bytes)


-- 
http://bugs.ruby-lang.org/