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: Nat Linden (nat_at_[hidden])
Date: 2013-06-26 08:29:05

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.

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.

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