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.
But you have not (and for a good reason!). So this argument is moot.
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.
The only benefit you're getting from using fibers for this (and you could achieve the same semantics using plain ol'threads as well, Boost.Asio is doing it for years after all) is - now guess - performance. So please make up your mind. Are you trying to improve performance or what?
If you don't need the extra performance - use std::thread.
I could have choosen a different API.
As said, you didn't. So this is moot.
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.
Who cares about this if not for performance reasons. However I still believe, that Fibers _are_ threads. You can't do anything with them you couldn't do with std::thread directly (semantically).
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.
Care to elaborate? Why is this false? You're implementing the Standards API with Standards semantics and constrain the usability of the outcome to a couple of minor use cases. Sorry, still no new semantics.
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.
Performance is never an after-thought. Your implementation quality so far is not up to Boost standards (as others have pointed out), the performance of the library is not convincing either. I'd suggest you withdraw your submission at this point, rework the library and try for another review once that's achieved. We have more substandard code in Boost already than necessary because of this 'let's fix it later' attitude. This 'later' never happens, most of the time - sadly. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu