From: "Ara.T.Howard" Date: 2004-06-10T00:43:49+09:00 Subject: Re: oddities with select On Wed, 9 Jun 2004, Ben Giddings wrote: > What I'm actually using is pretty close to that: > > def internal_read(timeout=DEFAULT_TIMEOUT, stop_pattern=nil) > retval = "" > > timed_out = false > > begin > timeout(timeout) do > while true > if select([@sock], [], [], 0.1) > retval += @sock.recv(256) > if stop_pattern > if retval =~ stop_pattern > break > end > end > end > end > end > rescue Timeout::Error > timed_out = true > end > > > # if timed_out > # puts "Timed out" > # raise > # end > > retval > end > > The problem is that although I've seen a newline go over the network to > my PC, it is never spotted by the Ruby app, which sits there doing the > 'select' forever. > > Your code looks slightly different, but I think it would do the exact > same thing. > > For some reason, the newline goes over the network, but doesn't make it > far enough (in 5s) that the 'select()' call sees it. > > Ben didn't you say something about your socket being in non-blocking mode? if so, isn't this just a busy loop since select will keep returning 'true - a read will not block': man 2 select ... three independent sets of descriptors are watched. those listed in readfds will be watched to see if characters become available for read- ing (more precisely, to see if a read will not block - in particular, a file descriptor is also ready on end-of-file) ... if not in non-blocking mode, perhaps your pattern is bad? what happens if you do this: > while true > if select([@sock], [], [], 0.1) > retval += @sock.recv(256) p retval ?? do you see retval growing? -a -- =============================================================================== | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov | PHONE :: 303.497.6469 | A flower falls, even though we love it; and a weed grows, even though we do | not love it. --Dogen ===============================================================================