On Wed, 9 Jun 2004, Ben Giddings wrote: > Ara.T.Howard wrote: >> don't you want to block? i mean, isn't that why you are using select? >> to do >> nothing until data arrives? if it IS blocking your code should sleep >> untill >> data becomes available. > > Actually, no. What I want to do is know that a command was accepted > (indicated by a blank line), unfortunately the code that I'm talking to > doesn't always do the right thing, so I want to bail out eventually if > it isn't going to happen. > > What I want to do is: "Try to read until you get a blank line, for a > maximum of N seconds" why not something along the lines of this buf = '' t = Thread.new{ loop{ buf << io.getc } } sleep n_seconds t.kill case buf when %r/^$/o raise "command not accepted" when %r/^\s+$/o # # handle command # else raise "bad response <#{ buf.inspect }>" end ?? > I know that some commands will go quickly, giving me a blank line in > under 200ms, and others will take a few seconds to complete, but if > they're taking 500ms and say 4.5s respectively, I want to stop waiting. > >> also, i'm not sure what the buffering semantics of select are - but i'm >> sure >> there are some - might want to check that out too... > > Hmm, ok... I thought select just told you when there was data available, and > either blocked or didn't, based on the timeout parameter you give it. > That's why I thought that I could essentially poll it with a low timeout > value, and when data became availble, I could use 'recv' to read it. > > Ben no - you are correct. ignore me! it's just that you don't know how MUCH data is available - only that it is, or that it's eof. -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 ===============================================================================