[sorry for joining the discussion so late]
On Thu, Jan 16, 2014 at 12:35 PM, Oliver Kowalke
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.
I think that Harmut point is that you can very well use threads for the same thing. In this particular case you would just perform a syncronous read. Yes, to mantain the same level of concurrency you need to spawn ten of thousands of threads, but that's feasible on a modern os/hardware pair. The point of using fibers (i.e. M:N threading) is almost purely performance. -- gpd