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.
Strongly disagree with your assumption. To me it's the semantics of Boost.Fiber that matter.
The semantics are well defined by the C++11 Standard, no news here.
Before launching any code on a new thread, both Boost.Thread and std::thread require that you must sanitize that code against potential race conditions. With a large, ancient code base, that sanitizing effort becomes almost prohibitive. Running one thread with multiple fibers is guaranteed to introduce no new race conditions.
If that's the case, then why does Boost.Fiber provide synchronization primitives to synchronize between fibers and support for work stealing? Or why is it implemented using atimics all over the place? Your statement does not make sense to me, sorry.
Emulating the std::thread API is intended to minimize coder confusion -- not to provide a drop-in replacement.
That's only one particular use case. Clearly we're talking about two different viewpoints where mine focusses on a very broad application for this kind of library, while yours is trying to limit it to a small set of use cases. While I accept the validity of these use cases I think it's not worth having a full Boost library just for those. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu