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.
But you have not (and for a good reason!). So this argument is moot.
what I tried to tell is, that I the boost community could comme to the conclusion that the choosen API (thread-API or any another) is not appropriate for the suggested semantics. as the review figured out is that the thread-API would be accepted by the reviewers - and that's what I was referring with 'stable API for boost.fiber'.
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?
As I wrote before - with thread you would have to scatter your code with callbacks. With fibers you don't - you could write the code as it would by synchronous operations. That makes the code easier to read and understandable.