Comments on: Coming Soon: Async I/O http://pocoproject.org/blog/?p=87 News and discussion for the POCO Community Thu, 09 May 2013 12:05:16 +0200 http://wordpress.org/?v=2.8.5 hourly 1 By: Steven Burns http://pocoproject.org/blog/?p=87&cpage=1#comment-220 Steven Burns Sat, 01 Sep 2007 21:17:57 +0000 http://appinf.com/poco/blog/?p=87#comment-220 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. 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.

]]> By: alex http://pocoproject.org/blog/?p=87&cpage=1#comment-219 alex Tue, 19 Jun 2007 16:54:08 +0000 http://appinf.com/poco/blog/?p=87#comment-219 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. 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.

]]> By: Paschal http://pocoproject.org/blog/?p=87&cpage=1#comment-218 Paschal Tue, 19 Jun 2007 12:02:18 +0000 http://appinf.com/poco/blog/?p=87#comment-218 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. 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.

]]> By: guenter http://pocoproject.org/blog/?p=87&cpage=1#comment-217 guenter Tue, 19 Jun 2007 06:29:18 +0000 http://appinf.com/poco/blog/?p=87#comment-217 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. 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.

]]> By: Paschal http://pocoproject.org/blog/?p=87&cpage=1#comment-216 Paschal Mon, 18 Jun 2007 22:19:03 +0000 http://appinf.com/poco/blog/?p=87#comment-216 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 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

]]> By: alex http://pocoproject.org/blog/?p=87&cpage=1#comment-215 alex Mon, 18 Jun 2007 15:21:30 +0000 http://appinf.com/poco/blog/?p=87#comment-215 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? 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?

]]> By: guenter http://pocoproject.org/blog/?p=87&cpage=1#comment-214 guenter Mon, 18 Jun 2007 12:42:17 +0000 http://appinf.com/poco/blog/?p=87#comment-214 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. 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.

]]> By: Paschal http://pocoproject.org/blog/?p=87&cpage=1#comment-213 Paschal Mon, 18 Jun 2007 12:31:43 +0000 http://appinf.com/poco/blog/?p=87#comment-213 I have not used asio ( http://asio.sourceforge.net/ ) but it appears to be a strong candidate for standardization. Did you think of leveraging this library? I have not used asio ( http://asio.sourceforge.net/ ) but it appears to be a strong candidate for standardization. Did you think of leveraging this library?

]]> By: guenter http://pocoproject.org/blog/?p=87&cpage=1#comment-212 guenter Mon, 18 Jun 2007 07:11:20 +0000 http://appinf.com/poco/blog/?p=87#comment-212 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. 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.

]]> By: alex http://pocoproject.org/blog/?p=87&cpage=1#comment-211 alex Sun, 17 Jun 2007 12:33:31 +0000 http://appinf.com/poco/blog/?p=87#comment-211 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. 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.

]]>