On 8/10/05, Jose <jmalv04@gmail.com> wrote:
See my previous response. I think a well thought out boost scheduler/multiplexor module is needed.
The asio library really looks quite nice. It appears simple to use, is 100% header-based, doesn't require the use of threads, and uses the most scalable event demultiplexor supplied by the OS (epoll on Linux in the 0.3x version and IOCP on Windows). Its a very nice little library! Thanks for linking to it. I think I'm in love :-) That it doesn't use Boost.Threads itself should not be considered a strike against it. Nothing prevents its use in applications using Boost.Threads, as the asio maintainer stated in his earlier reply.
I would just focus on async network io in linux (preferably using epoll). Networking is one area where boost should probably have separate platform solutions so that best performance and elegance are not compromised.
On top of that, having an acceptor and connector implementation with basic http examples would go a long way towards advancing in the right direction.
What do you consider "the right direction"? Aside from the lack of higher-level examples, what do you think asio is lacking?
If you plan to do this then I would gladly use it and provide feedback. I would wait first for more opinions. I am coming from the newbie boost user perspective that wants to build networking apps easily and doesn't need ACE.
ACE is indeed overkill for *just* networking, but it is battle-tested, feature-rich, fast, and *very* portable. Like it or not, many of the patterns implemented in ACE are must-haves once you have a nice networking library and want to start writing more complex applications (logging, threads, synchronization primitives, message queues, active objects, etc.). Boost provides a number of these, but the sheer breadth, depth, and maturity of ACE makes for a very compelling library. -- Caleb Epstein caleb dot epstein at gmail dot com