2014/1/16 Hartmut Kaiser
I still don't get it. There is no API stability question. The API is well defined for over 2 years now in the C++11 Standard (and even longer in Boost.Thread).
I could have choosen a different API for fibers - but I think the developers are more familiar with std::thread/boost::thread API.
So performance is the main incentive for such a library (what could there be else?).
with fibers you can suspend your execution context while keep the thread running (might execute something else). this is not possible with threads if they are suspend (yield(), waiting on mutex/condition_variable). this feature of fiber enables you to write (again asio eve nif you don't care this use case). for (;;) { ... boost::asio::async_read( socket_, buffer, yield[ec]); ... } async_write() suspends the current execution context (not the thread itself) and resumes it if all data have been read. without fibers you can't write the code like above (for-loop for instance). in the thread itself you can have more than one fibers running such for-loops. with threads you would have to pass a callback to async_read() and you could not invoke it inside a for-loop. the example directory of boost.fiber contains several asio examples demonstrating this feature.
If you don't need the extra performance - use std::thread.
I could have choosen a different API.
Boost.Fiber does not add any new semantics beyond what the Standard mandates.
it adds 'suspend/resume' a execution context while the hosting thread is not suspended.
Instead, it adds more constraints to the context where the API can be used (somebody mentioned interaction with Asio, and single-threaded legacy applications) - thus it narrows down existing semantics.
I think this statement is false.
Sure, that's out of question. My concern is that we're about to add a Boost library targeting some minor use cases only, while it has the potential to change the way we do parallel computing.
be sure that I've performance on my target after this discussions! I've already started to write code for performance-measurements.