From: Robert Klemme Date: 2013-07-15T17:32:06+09:00 Subject: Re: closing a socket while another thread is in an IO.select() call on it --047d7bb03e6af8634004e188b1d3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 15, 2013 at 9:53 AM, Graham Menhennitt wrote: > Hello Rubyists, > > I have a program that opens a TCPSocket, connects it to a server, and > then creates a thread which loops until the socket closes, reading from > the socket and processing the data read. It calls IO.select() to wait > until there is data available to read. Why don't you just use a blocking read if you have a separate thread per socket anyway? Select is only useful if you want to have a single thread process several file descriptors. > Meanwhile, another thread can > close the socket in certain circumstances. If the first thread is in > IO.select() when the socket is closed, the result is unpredictable - > sometimes the select() returns and sometimes it blocks. I'm not sure of > the circumstances that cause it to block or not - it seems random. > Hmmm. That sounds a bit odd. I would have expected select to return. Maybe there's a race condition in the std lib. > So, is there some way to make it reliably unblock? Or is there something > that the second thread can do to cause the select() to return (set a > flag on the socket before closing it, or something)? > You could work with a timeout but that seems a bit like a workaround. > This is with Ruby 2.0.0 p247 on Centos 5 Linux if that's significant. > Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ --047d7bb03e6af8634004e188b1d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 15, 2013 at 9:53 AM, Graham Menhennitt <graham@= menhennitt.com.au> wrote:
Hello Rubyists,

I have a program that opens a TCPSocket, connects it to a server, and
then creates a thread which loops until the socket closes, reading from
the socket and processing the data read. It calls IO.select() to wait
until there is data available to read.

Why = don't you just use a blocking read if you have a separate thread per so= cket anyway? =A0Select is only useful if you want to have a single thread p= rocess several file descriptors.
=A0
Meanwhile, another thread can=
close the socket in certain circumstances. If the first thread is in
IO.select() when the socket is closed, the result is unpredictable -
sometimes the select() returns and sometimes it blocks. I'm not sure of=
the circumstances that cause it to block or not - it seems random.

Hmmm. =A0That sounds a bit odd. =A0I would have= expected select to return. =A0Maybe there's a race condition in the st= d lib.
=A0
So, is there some way to make = it reliably unblock? Or is there something
that the second thread can do to cause the select() to return (set a
flag on the socket before closing it, or something)?
<= br>
You could work with a timeout but that seems a bit like a wor= karound.
=A0
This is with Ruby 2.0.0 p247 on Centos 5 Linux if that's significant.
=A0
Kind regards

robert

=
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
--047d7bb03e6af8634004e188b1d3--