On Thu, Jun 27, 2013 at 11:38 PM, Oliver Kowalke
2013/6/28 Arash Partow
On 27/06/2013 Oliver Kowalke wrote:
boost::asio:yield_context - uses internally boost.coroutine boost::fibers::asio::yield - uses internally boost.fiber
both rely on boost.context
A completely irrelevant statement.
tried to express that coroutines and fibers are different abstractions over the same scheduling model
The gist of my previous comment was not about the details of the coroutine facilities in asio, but rather the fact that said semantics were already available within the stock asio interface and that perhaps before attempting to integrate another interface/library into the OPs solution, they could attempt to see if the already available facilities in asio would meet their needs - which would include as you suggested taking into account the various performance criteria and "programming models".
'programming models' - event-based, multithreaded, combination of both?
with boost.asio scattering your code with multiple callbacks ...
Yessir, precisely my observation as well. Looks like it will be so much easier to compose client/server concerns now.
the main benefit of using coroutines or fibers is that you can program your code straight forward. with the 'old' callbacks in asio you have to split your logic in multiple functions/callbacks called by the async-ops.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users