«

How can I perform a nonblocking IO read? That is, read whatever is
there to read and return. If there's nothing yet, just return.

Failing that, is there a way to manually check if there's anything to
read or the read will block?

(Note that I'm developing for both 'nix and Windows.)

On Wed, 1 Nov 2006 wrote:

> How can I perform a nonblocking IO read? That is, read whatever is
> there to read and return. If there's nothing yet, just return.
>
> Failing that, is there a way to manually check if there's anything to
> read or the read will block?
>
> (Note that I'm developing for both 'nix and Windows.)

it can't be done. search the archives, this sort of thing almost always
indicates a design flaw. for instance - what will your program do if there is
no input?

regards.

-a
--
my religion is very simple. my religion is kindness. -- the dalai lama

On Oct 31, 2006, at 6:23 PM, wrote:
> On Wed, 1 Nov 2006 wrote:
>> How can I perform a nonblocking IO read? That is, read whatever
>> is there to read and return. If there's nothing yet, just return.

That's what the Unix read() function does ("man 2 read"), available
in Ruby as IO#sysread(). The ri documentation doesn't explain much
about how to use Ruby's sysread, unfortunately.

>> Failing that, is there a way to manually check if there's anything
>> to read or the read will block?
>>
>> (Note that I'm developing for both 'nix and Windows.)

The select() function (Kernel#select, in Ruby) is the standard way to
do IO multiplexing under Unix. You give it a list of file handles on
which you're waiting to be able to read or write, and it returns when
one or more of them is ready. Windows provides a select() function,
too, but it only supports sockets (not pipes or ordinary file IO.)
The Win32 API generally doesn't provide non-blocking IO methods,
because it's assumed you'll use threads if you want to do something
else while waiting for IO.

> it can't be done. search the archives, this sort of thing almost
> always
> indicates a design flaw. for instance - what will your program do
> if there is
> no input?

Check other IO channels, wait for other sorts of events, do work -
whatever. Where do come from asserting that the use of non-blocking
IO represents a "design flaw"?

Tom

wrote:
> On Wed, 1 Nov 2006 wrote:
>
> > How can I perform a nonblocking IO read? That is, read whatever is
> > there to read and return. If there's nothing yet, just return.
> >
> > Failing that, is there a way to manually check if there's anything to
> > read or the read will block?
> >
> > (Note that I'm developing for both 'nix and Windows.)
>
> it can't be done. search the archives, this sort of thing almost always
> indicates a design flaw. for instance - what will your program do if there is
> no input?

I'm running an external command (using popen4 - yes, it is available on
Windows also). I capture stdout and stderr. "what will your program do
if there is no input?" - I assume you mean output - Well, I hope there
is no stderr output. If there is, I'd like to capture it and feed it
to Logger.

Likewise, if there is a problem, and there's no stdout, then I don't
want to wait for ever - I want to throw an exception.

In the interests of promoting creativity, I'll ask the question without
any prior assumptions:

I'm using popen4 (great gem, btw) to run an external command and
capture stdout and stderr. If one (or both) of those is empty, I don't
want to hang. Just keep on moving. In fact, stderr will normally be
empty.

How could I do this?

(I'm supporting 'nix and Windows)

On Wed, 1 Nov 2006, Tom Pollard wrote:

>
> On Oct 31, 2006, at 6:23 PM, wrote:
>> On Wed, 1 Nov 2006 wrote:
>>> How can I perform a nonblocking IO read? That is, read whatever is there
>>> to read and return. If there's nothing yet, just return.
>
> That's what the Unix read() function does ("man 2 read"), available in Ruby
> as IO#sysread(). The ri documentation doesn't explain much about how to use
> Ruby's sysread, unfortunately.

no, that blocks. try this:

harp:~ > ruby -e 'STDIN.sysread(1)'

it blocks. the OP wants a non-blocking call. eg

harp:~ > ruby -r io/nonblock -e 'STDIN.nonblock{ STDIN.sysread(1) }'
-e:1:in `sysread': Resource temporarily unavailable (Errno::EAGAIN)
from -e:1
from /home/ahoward//lib/ruby/1.8/io/nonblock.rb:19:in `nonblock'
from -e:1


> The select() function (Kernel#select, in Ruby) is the standard way to do IO
> multiplexing under Unix. You give it a list of file handles on which you're
> waiting to be able to read or write, and it returns when one or more of them
> is ready. Windows provides a select() function, too, but it only supports
> sockets (not pipes or ordinary file IO.) The Win32 API generally doesn't
> provide non-blocking IO methods, because it's assumed you'll use threads if
> you want to do something else while waiting for IO.

right. but ruby's thread are green and, on windows, block the entire process
when waiting on IO so not an option here.

> Check other IO channels, wait for other sorts of events, do work - whatever.
> Where do come from asserting that the use of non-blocking IO represents a
> "design flaw"?

because nine times out of ten code has nothing to do if no input is available.
if it does that's another story, but then there are basically two options:

- use select or an event abstraction in one giant loop. if you do this you are
going to block anyhow, only based on all inputs, not just one.

- use threads, only you can't if you're wanting ruby code to run nb in windows.


i'm not saying there is never a case for nbio - i use it myself - just that,
unless a developer has a good reason to be doing something else it's not
required and, as a search of ruby-talk will show, that is often the case.

regards.

-a
--
my religion is very simple. my religion is kindness. -- the dalai lama

On Wed, 1 Nov 2006 wrote:

> I'm running an external command (using popen4 - yes, it is available on
> Windows also). I capture stdout and stderr. "what will your program do if
> there is no input?" - I assume you mean output - Well, I hope there is no
> stderr output. If there is, I'd like to capture it and feed it to Logger.
>
> Likewise, if there is a problem, and there's no stdout, then I don't want to
> wait for ever - I want to throw an exception.

so, basically you want to timeout on a read right? in unix you can just use

require 'timeout'

Timeout::timeout(n) do
Open4.popen4 ...
...
...
end

but, this is implimented via a thread so i think the read is going to block
your entire process in windows... you might try it.

-a
--
my religion is very simple. my religion is kindness. -- the dalai lama

Not very attractive...

Back to the original question: there is no simple way to read
nonblocking, or see if any output is available ?!?!


wrote:
> On Wed, 1 Nov 2006 wrote:
>
> > I'm running an external command (using popen4 - yes, it is available on
> > Windows also). I capture stdout and stderr. "what will your program do if
> > there is no input?" - I assume you mean output - Well, I hope there is no
> > stderr output. If there is, I'd like to capture it and feed it to Logger.
> >
> > Likewise, if there is a problem, and there's no stdout, then I don't want to
> > wait for ever - I want to throw an exception.
>
> so, basically you want to timeout on a read right? in unix you can just use
>
> require 'timeout'
>
> Timeout::timeout(n) do
> Open4.popen4 ...
> ...
> ...
> end
>
> but, this is implimented via a thread so i think the read is going to block
> your entire process in windows... you might try it.
>
> -a
> --
> my religion is very simple. my religion is kindness. -- the dalai lama

On Oct 31, 2006, at 5:30 PM, S. Robert James wrote:

> Not very attractive...
>
> Back to the original question: there is no simple way to read
> nonblocking, or see if any output is available ?!?!

in io/wait:

--- IO#ready?
returns non-nil if input available without blocking, or nil.

also: ri IO.read_nonblock

[]
|
| it can't be done. search the archives, this sort of thing almost
| always indicates a design flaw. for instance - what will your
| program do if there is no input?

nonblocking IO is not a design-flaw; it is something that is in common
use and is supported by most languages with a decent socket API. on
some OS'es this is even available for file IO (although widespread
language support seems to lag behind).

Java for example got proper nonblocking socket IO in 1.4 (see
JSR-000051 "New I/O APIs for the JavaTM Platform").

for examples of use you might want to check out the Reactor pattern
and other patterns for concurrent programming.

-Bjørn