2013/6/25 Nat Linden

You might also consider using Boost.Context to manage Asio state. I think there are Context examples dealing with Asio.

Instead of boost.context I would suggest using boost.fiber ( github.com/olk/boost-fiber). The lib provides user-land threads (cooperative scheduling -> context switching) and integrates into boost.asio's new async_result-feature (currently in trunk - might be available in boost-1.54). boost.fiber contains some examples dealing with async_result (examples adapted from boost.asio): timer_.expires_from_now( boost::posix_time::seconds( 3) ); std::size_t n = socket_.async_read_some( boost::asio::buffer( data), boost::fibers::asio::yield); boost::asio::async_write( socket_, boost::asio::buffer( data, n), boost::fibers::asio::yield);

2013/6/26 Bjorn Reese

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 Which lib you choose depends on your preferred programming model.

On Wed, Jun 26, 2013 at 7:29 AM, Nat Linden wrote:

On Wed, Jun 26, 2013 at 5:35 AM, Oliver Kowalke wrote:

...

2013/6/26 Bjorn Reese

...

...

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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

On Wed, Jun 26, 2013 at 10:39 AM, Arash Partow wrote:

On 26/06/2013 7:11 PM, Bjorn Reese wrote:

...

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?

Not guidance per se but here's a nice example:

https://github.com/chriskohlhoff/asio/blob/master/asio/src/examples/cpp11/sp...

It's an asio example, but doesn't address the question about Context, Coroutine or Fiber.

2013/6/27 Arash Partow

The trick is to click the link, read and comprehend the code example, at which point an astute individual may realize that CK has gone to a lot of effort to integrate coroutine semantics into stock asio within the context of C++11.

boost::asio:yield_context - uses internaly boost.coroutine boost::fibers::asio::yield - uses internaly boost.fiber both rely on boost.context

1. Do I use another library to provide the functionality I think I may need?

as I wrote it depends on your programming model - with coroutine-version (boost::asio:yield_context) you only operate in the asio-related context with fiber version (boost::fibers::asio::yield) you get a broader range of usage == for instance the one-thread-for-one client (10k-problem) can easliy be used with boost.fiber + boost.asio (boost::fibers::asio::yield) without degrading over-all performance (at a certain amount of threads scheduling overhead inside the OS counts + context switching between threads). you can use mutex, condition-vars .... to sync fibers etc.

Oh and btw the example quoted above quite clearly deals with the OP's original problem in a clean, efficient and simple to understand manner and so to the many other examples related to timeouts in the asio example set, all it takes is a bit of tinkering.

boost.fiber contains this example adapted to use boost.fiber

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 ... 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.

On Wed, Jun 26, 2013 at 9:39 AM, Arash Partow wrote:

On 26/06/2013 7:11 PM, Bjorn Reese wrote:

...

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?

Not guidance per se but here's a nice example:

https://github.com/chriskohlhoff/asio/blob/master/asio/src/examples/cpp11/sp...

Looks like that spawns a couple of strands of lambdas. The same thing could be done with member functions? We don't have an echo server, but would be reading event messages from a client in one strand, then adapting some sort of subscriber/channel pub/sub push/pull methodology to send event messages to the client. I gather with the asio io_service strand approach, that is running a couple of threads concurrently? I am noticing the steady timer shared between both strands, for instance. Thanks!

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

On Wed, Jun 26, 2013 at 9:39 AM, Arash Partow wrote:

On 26/06/2013 7:11 PM, Bjorn Reese wrote:

...

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?

Not guidance per se but here's a nice example:

https://github.com/chriskohlhoff/asio/blob/master/asio/src/examples/cpp11/sp...

This is a different version of boost? Because I can't seem to find spawn.hpp in version 1.53 that I downloaded.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users