Boost logo

Boost :

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


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


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

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

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.


--- 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
> design or implement such a library. If no one else will work on
> I will have to do it myself, but then I probably will not be able
> 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
> will ever benefit from it.

Boost list run by bdawes at, gregod at, cpdaniel at, john at