Socket's close() doesn't close connection (old bug?)

Tue Nov 8 16:24:00 GMT 2005

Just continuing in my own personal forum...
>>> In my eager to reproduce another bug I've stumbled across yet another 
>>> strange issue - namely that Socket's close() doesn't close underlying 
>>> socket (with no traffic), nor "wake up" a blocked read-thread (as a 
>>> consequence)...
>> Blah blah blah, this turned out to be reported already:
>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430
>>>> Unfortunately still open ;-)

> It seems that if you set the SoTimeout value, so that read() returns, 
> the socket will be closed after returning the blocking thread.
> So I guess it's only a matter of interrupting any blocking thread when 
> close() is invoked - then everything will be good?!
>> (My naive thoughts - I'll look into the implementation in a moment to 
> see if this is possible in any easy matter...)

Well, it seems like one can do the following:
1) Register the thread invoking read() (and its siblings) in 
"natPlainSocketImplPosix.cc".
2) When closing the socket (also in natPlainSocketImplPosix.cc), a flag 
should be set true, and the thread cached from before should be interrupted.
3) Back in read(), the flag is examined for why the read was 
interrupted, returning a correct exception to the user.
That's a small workaround...
// Martin