Re: Non-blocking I/O

From: Paul Carter (paul.carter_at_[hidden])
Date: 2001-03-06 09:11:10

Hi,

I've done a fair amount of asynchronous I/O on Windows NT, so I 
thought I'd run this one past my little grey cells...

There is (as always) a number of issues to address in implementing 
asynchronous (or non-blocking) I/O using the std iostream model.  
I'll summarise some of the issues (i.e. the one's that have sprung to 
mind so far) and follow up with some options for addressing them. 

i/ What should the end-user interface look like?  Obviously, it's 
going to look quite like std::iostream, but there are variations.

ii/ At what level do we abstract out the OS-specific functionality

iii/ How & when do we notify completion to the user

iv/ How do we support an OS with no async facilities

v/ How do we handle operations that don't map well to asynchronous 
i/o?

etc.

Ok, so how should we address these issues?

i/ (what's the UI)
Support could be through a stream adapter class
(e.g. async_ostream acout(cout);  acout << o;)
Using manipulators
(e.g. cout << async(o); or cout << async << o;)
I think that there is little point in producing a complete hierarchy 
of async_stream and async_streambuf classes, we should be aiming to 
provide a flexible solution that can support asynchrounous I/O on all 
streams, including user-defined ones with a minimum of user effort.

ii/ (abstraction of OS functionality)
A set of policy or traits classes will be required allowing 
specialisation by OS and I/O type, providing a common interface to 
the low-level OS functions.  Note that Windows NT has more than form 
of async support.

iii/ (completion notification) 
Different applications can require different types of io completion 
notifications, e.g. none, callbacks, polling etc.  An async stream 
should be flexible and extensible in this regard. It might be 
advantageous to allow multiple and/or dynamic notification 
specification.

iv/ (OS support)
Some OS's don't support async operations or will only support them 
for certain types of I/O.  A default thread-based scheme could be 
used in these cases.  For single-threaded OS's the streams should 
either by unsupported or fall back to blocking mode.

v/ (non-sensical operations)
Some standard stream operations won't map well to asynchronous I/O, 
for instance the operation of an istream iterator could be confusing 
to a user.  Also, accessing lower level streambuf operations could 
break things.  I think this issue is best left for detailed 
consideration until a draft implementation is available for 
discussion.

Unless someone pops up with any objections - or a good solution of 
their own, I'll try to bash out a draft (Win32) implementation in the 
next week or so.

Paul

--- In boost_at_y..., pinkfloydhomer_at_y... wrote:

> --- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> > At 11:23 AM 3/4/2001 -0600, Ed Brey wrote:
> > 
> > Good point.  Hopefully that will get captured for the Library's 
> rationale.
> > 
> 
> So, will anybody want to work on this non-blocking I/O addition to 
> the library?
> 
> I would like to help myself, but I'm not sure I am the best person 
to 
> design or implement such a library. If no one else will work on 
this, 
> I will have to do it myself, but then I probably will not be able 
to 
> make a good enough design that it deserved to be in boost. I would 
> probably just make it work for my particular application, and no 
one 
> will ever benefit from it.