
IMHO, Boost.Fiber is a library which - unlike other Boost libraries - has not been developed as a prototype for a particular API (in which case I'd be all for accepting subpar performance). It clearly has been developed to provide a higher performing implementation for an existing API. That means that if Oliver is not able to demonstrate superior performance over existing implementations, I wouldn't see any point in having the library in Boost in the first place.
As I explained several times in this review - boost.fiber aims to provide a way to synchronize/coordinate coroutines as it was requested on the dev- list some months ago. -> boost.asio
In that case you might be surprised to learn that libraries often have a life of their own which opens up unexpected opportunities way beyond whatever you might have imagined. IHMO it is a mistake to constrain Boost.Fiber to just what you said as this is only a minor use case (as convenient as it might be) for such a library. Threading with minimal overheads supporting fine grain parallelism is the future. Building convenient means for managing that parallelism is the future. Application scalability, which today might be just a problem for high end computing problems, gains footprint in everyday computing at an exceptionally high rate. Two years from now, my desktop will support 288 concurrent threads (Intel Knight's Landing [1]). Massive multi-threading is here to stay. At the same time, application scalability is limited by the 4 horsemen of the apocalypse [2]: Starvation, Latencies, Overheads, and Waiting for contention resolution (SLOW). IOW, minimizing overheads is one of the critical pieces of the puzzle. Libraries such as Boost.Fiber are critical to solve the problems of insufficient scalability and parallel efficiency achievable by using existing technologies only. Wake up Oliver - you're up to the forefront of parallel computing and you don't realize it! Boost has to define the future of C++ libraries (as imposed on us by the computer architectures to come), it has not to focus on covering the past. Let's not let this opportunity slip. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu [1] http://www.extremetech.com/extreme/171678-intel-unveils-72-core-x86-knights- landing-cpu-for-exascale-supercomputing [2] http://stellar.cct.lsu.edu/2012/01/is-the-free-lunch-over-really/