Re: [Boost-users] [asio] How to deal with no-connect and/or read-timeout

Subject: Re: [Boost-users] [asio] How to deal with no-connect and/or read-timeout
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2013-06-28 10:06:53

On Thu, Jun 27, 2013 at 11:38 PM, Oliver Kowalke
<oliver.kowalke_at_[hidden]> wrote:
> 2013/6/28 Arash Partow <arash_at_[hidden]>
>>
>> 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users