2013/6/28 Arash Partow <arash@partow.net>
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 ...

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.