Wake up Oliver - you're up to the forefront of parallel computing and you don't realize it!
why do you allege that?
I was hoping to raise your awareness that you're up to something much bigger than 'just' fibers. I didn't mean to offend and I apologize if I did.
for me semantics and usability of boost.fiber is more important than performance. performance tuning is mostly an issue of implementation details and can be done after the API is stable and proven.
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). So performance is the main incentive for such a library (what could there be else?). If you don't need the extra performance - use std::thread. Boost.Fiber does not add any new semantics beyond what the Standard mandates. 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.
but this might not to apply to all developers - you are free to choose the tool of your preference.
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. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu