Re: Non-blocking I/O

From: pinkfloydhomer_at_[hidden]
Date: 2001-03-05 04:09:08

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 03:13 PM 3/3/2001 +0000, pinkfloydhomer_at_y... wrote:
> 
>  >Would a non-blocking I/O library addition be off topic in Boost, 
or
>  >wouldn't it?
> 
> It certainly wouldn't be off topic for Boost.
> 
> But I wonder if it would actually result in a performance 
improvement on 
> most modern operating systems.
> 
> Don't most OS's already do anticipatory buffering?  Have you run 
timings?
> 

For me, it's not a timing issue. It's a functionality issue. In my 
particular case, I am developing a chess engine (a chess playing 
program), in C++. For the sake of portability, it is kept as much as 
possible an adherence to the ANSI standard. My problem is, that I 
have to way to listen for input from stdin non-blockingly, while 
performing the search in the gamespace. So I have to use platform 
specific stuff. And even worse is the fact that on the Windows 
platform, this cannot be done device-independantly, but has to be 
done seperately for keyboard input and piped input.
In my case, I don't really need that much functionality, I just want 
to know if an entire line (ending with a \n) is in the buffer or not. 
If it isn't, I ignore the input. But as soon as there is an entire 
line in the buffer, I read it and act on it. I poll a number of times 
a second during search in my case.

Even if I would be extremely happy to have such a feature in C++ 
(seeing that this feature is natively available on all the platforms 
that I would ever want my program to work on), this is not just a 
case of "I want this in my program, why hasn't it been done for me? 
Please add it to the standard". I really think that this feature is 
very general (a stream with non-blocking input capabilities), and 
naturally models a huge amount of logical and physical devices on 
real computers. Just as files, printing output, adding integer values 
etc. is very common.