The POCO C++ Libraries Blog

Coming Soon: Async I/O

Filed under: News by guenter at 11:58

During a very relaxing one hour run through the forest yesterday, I suddenly had an idea how to implement asynchronous I/O for streams and sockets in POCO with very little effort. I’m going to try my ideas out today, so you can expect to show up something in the SVN repository tomorrow – it shouldn’t take more than a few hours to implement this, using existing features in POCO.

Update: AsyncIO is in SVN

  1. Is this a new/separate library and does it in any way relate to the IO library we have in the sandbox? I have some projects depending on that code.

    Comment by alex on June 17, 2007, 14:33

  2. Implementing the whole AsyncIO thing took me about 3 hours (with interruptions), including testing. From an implementation point of view, the thing is rather simple: it combines ActiveMethod, ActiveDispatcher, events and the command pattern in an elegant way. I/O commands (AsyncIOCommand and subclasses) can be queued for execution on an AsyncIOChannel. Events are fired when a command completes. It is also possible to wait for the completion of a command.

    The only drawback of the implementation is that it does not use the native operating system facilities for asynchronous I/O, but rather emulates asynchronous I/O using blocking I/O operations and a separate I/O thread. However, the advantage of this solution is that it’s much simpler to implement (cross platform native async I/O is veeery messy…), works with all possible I/O devices (like iostreams and sockets) and works consistently across all platform. Also, I consider the performance impact rather minimal. I hope you’ll like it.

    The thing is part of the Foundation library (AsyncIOChannel, AsyncStreamChannel, AsyncIOEvent, AsyncIOCommand and subclasses). Async IO for sockets is implemented in the Net library in AsyncSocketChannel.

    Comment by guenter on June 18, 2007, 09:11

  3. I have not used asio ( ) but it appears to be a strong candidate for standardization. Did you think of leveraging this library?

    Comment by Paschal on June 18, 2007, 14:31

  4. Not really. I haven’t at it in detail, but I am a bit suspicious about libraries consisting entirely of header files. Also, the current implementation uses existing facilities in POCO and requires very little additional code. Changing ASIO so that it works with the rest of POCO in a consistent and intuitive way would be just too much work.

    Comment by guenter on June 18, 2007, 14:42

  5. From what I’ve been able to see in code so far, it looks good. Now that we have AsyncIOChannel, can we also have an Poco::IOChannel abstraction in Foundation? That would give us a common abstract interface for use in IO library. Right now, I have kindof messy solution there with dependency on Foundation and Net.

    About ASIO:

    Paschal, where did you get the the information that asio is a “strong candidate” for standard? All I was able to find is a proposal for TR2.

    Guenter, other than aesthetically-based bias against header-only libs, is there something else that makes you being suspicious toward them?

    Comment by alex on June 18, 2007, 17:21

  6. I thought being proposed for inclusion in the TR2 gives asio a good chance to be in the standard at some point. There may well be stronger candidates; I just don’t know about them.
    Having said that I am not a fan of boost libraries. Not because they are ( most are ) headers only but because they tend to increase my compile times exponentially

    Comment by Paschal on June 19, 2007, 00:19

  7. The two main reasons why I don’t like header only “libraries” are first that they increase compile times significantly, and second, that they increase code size. The latter is not true if you build statically linked executables. However, if you depend heavily on shared library (like any application built using POCO OSP, for example), then all of the code of a header-only library gets basically duplicated in every shared library that uses it. On a typical PC with 1 GB of RAM this is not a problem, but if you’re targetting an embedded device with 64 or 256 MB or RAM this becomes a serious issue.

    Comment by guenter on June 19, 2007, 08:29

  8. There is at least one clear advantage with headers only libraries. The ease with which you can integrate them into your own project. Unfortunately with Boost even a tiny library heavily depends on the presence of a large chunk of Boost such that for me the compile /link cost outweighs the convenience of project integration. Boost is becoming more and more like a framework.

    Comment by Paschal on June 19, 2007, 14:02

  9. I agree on boost. I have heard Stroustrup complaining about exactly the same thing. The fact that boost is growing into framework only proves that modular design as a panacea (just like OO reuse) is a pie in the sky. Because of this incoherent growth, I predict boost to keep on losing popularity for real world apps. Proper design is through frameworks/patterns and proper development model is incremental/iterative, going hand-in-hand.

    Comment by alex on June 19, 2007, 18:54

  10. I agree, Boost suffers from incoherent growth. It’s full of libraries only some few will use (quaternions, octonions, an LL parser, finite state machines, graph-math, etc).
    But as of this writing, Boost provides no libraries for mundane things like reading XML files or sending an HTTP request to a web server.
    Boost ASIO is great though, and it does use the native OS async I/O facilities. But its not a full blown networking library and it’ll never be.

    Comment by Steven Burns on September 1, 2007, 23:17

RSS RSS feed for comments on this post. TrackBack URI

Leave a comment