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-26 09:09:48

On Wed, Jun 26, 2013 at 7:29 AM, Nat Linden <nat_at_[hidden]> wrote:
> On Wed, Jun 26, 2013 at 5:35 AM, Oliver Kowalke
> <oliver.kowalke_at_[hidden]> wrote:
>
>> 2013/6/26 Bjorn Reese <breese_at_[hidden]>
>
>>> On 06/26/2013 08:48 AM, Oliver Kowalke wrote:
>>>
>>>> Instead of boost.context I would suggest using boost.fiber
>
>>> Could you provide some guidance about the pros and cons of
>>> Context versus Fiber versus Coroutine so that we are in a better
>>> position to select the appropriate module?
>
>> boost.context - low-level library, provides mechanism to switch between
>> execution context (assembler etc.)
>> boost.coroutine - uses boost.context, resume-and-suspend explicitly
>> execution of coroutine-fn,
>>                          for example docu show how to use a coroutine to
>> suspend reading from a std::stream (special character was not received ->
>> usually stream blocks)
>> boost.fiber - uses boost.context, provides a framework like boost.thread,
>> fibers not explicitly resumed/suspended (done by mutext/condition/barrier
>> ...), all fibers run concurrent
>>                   in the same thread
>
> I should have suggested Coroutine instead of Context. Boost.Context is
> a lower-level API on which to build high-level APIs such as Coroutine
> and Fiber. It exists as a separate library in case your high-level API
> needs are not met by either Coroutine or Fiber. Apologies.
>
> To my mind, there are two key distinctions between Coroutine and Fiber.
>
> As Oliver says, a coroutine is called, yields some value to its
> caller, and is called again with another set of parameter values. To
> its caller it resembles an ordinary function call. But within the
> coroutine, the yield operation itself behaves like a function call:
> you yield a value and then, on being called again, resume execution
> from the same point in your coroutine. This can involve arbitrary
> recursion; a coroutine is a straightforward way to implement, say,
> iterators over a tree structure.

Right. That's basically what we're doing now, I believe.

> A fiber more closely resembles a thread. It runs independently of the
> code that launches it; communication between fibers is arranged using
> mechanisms that resemble inter-thread communications. It's just that
> context switching between fibers is massively cheaper than context
> switching between threads -- and two fibers *cannot* race to access
> the same data. While one fiber is running, you know that other fibers
> in the same thread are not. Therefore data shared between fibers are
> always in a known state.

I scanned over the fiber repo examples, and this does look like a
compelling way to simplify the whole approach IMO.

> The other key distinction is that Coroutine is already an official
> Boost library. Fiber is "coming soon."

There is that, which we need an approach today.

I am looking forward to the Git-submodule approach in future versions
of Boost, however. Far cry from the monolithic repo, but for an
interest to back up local copies of all source, built or otherwise.
But that's a topic for another time.

> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users