With Boost.Fiber does c++ come one step closer to Erlang style process/threads?

Ivan picture Ivan · Nov 19, 2014 · Viewed 8k times · Source

I am reading http://olk.github.io/libs/fiber/doc/html/ It seems to me that with Boost.Fiber C++ is coming closer to Erlang's ability to have thousands of "processes", also known as "green processes[threads]" http://en.wikipedia.org/wiki/Green_threads.

My question is, is Boost.Fiber ready for production, are there now c++ alternatives that have better documentation and examples? Someone mentioned lightweight threads, but I can't seem to find a reference to it. One final question is, why doesn't the C++ standard include Fibers?

The reason I am interested in this is because I have realtime updates where a value change can impact (spawn) hundreds/thousans of small but embarrassingly parallel computations. The C++ thread model doesn't work very well, imo. Please no GPU, since it currently takes too long to transfer the information to and from the GPU.

I realize that Erlang is far more than this so please don't educate me on Erlang vs C++ in the general case.

Answer

Niall Douglas picture Niall Douglas · Jan 10, 2015

Boost.Fiber was reviewed by the Boost community in January 2014 and was found to need significant additional work. See the results of the community review at http://lists.boost.org/boost-announce/2014/01/0393.php.

C++ 17 also looks to gain a WinRT like M:N threading model based around resumable functions using the proposed await keyword. Microsoft have implemented support in their compiler, and apart from magic memory allocation tricks for futures it looks very promising. The relevant N paper is N4134 (http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2014/n4134.pdf), and as you will see that if accepted, this formulation of resumable functions would indeed provide Erlang type scalability even if the syntax is a bit obtuse (hey, it's C++, when is its syntax ever straightforward!).

Of course, if you need a portable solution now, either go the stackless coroutine route with ASIO (caution: it's brittle), or finely grain ASIO handlers with ASIO strands using a class instance as your execution state which is much the same thing, or else use Boost.Fiber anyway. If you only need Windows, I'd press ahead with Microsoft's proprietary extensions myself, they are highly unlike to abandon them unless they abandon WinRT :)

Edit: The author of Boost.Fiber tells me that as of January 2015 the recommended changes from the community review are complete, and apart from documentation improvements Fiber is considered ready for inclusion into official Boost. If this is indeed the case, then Fiber is probably the best solution before official C++ 17 language support for final resumable functions appears in compilers.