I think that Harmut point is that you can very well use threads for the same thing. ... The point of using fibers (i.e. M:N threading) is almost purely performance.
Again, for a large class of use cases, fibers and threads are not the same.
Writing thread-safe code remains something of an art, a specialty within the already-rarefied realm of good C++ coding. With care, code review and testing, it is of course possible to produce good thread-safe code when you are writing it from scratch.
But retrofitting existing single-threaded code to be thread-safe can be extremely costly. At this moment in history, we have a very large volume of existing code whose developers (perhaps unconsciously) relied on having exclusive access to certain in-process resources. Some of us do not have the option to discard it and rewrite from scratch.
Yes, this is a subset of the possible use cases of the Fiber library. It is an important subset because threads provide no equivalent.
If the main target of Boost.Fiber is this use case (support 'multi-threading' in single threaded applications), then the way it's implemented does not make sense to me. Why would you need a single atomic if all you have is a single thread? And the source code has atomics all over the place - thus I gather this use case was not what Oliver had in mind.
Yes, I also want a Boost library that will concurrently process very large numbers of tasks, with each of a number of threads running very many fibers. I think the Fiber library gives us a foundation on which to build that support. But even with its present feature set, with Oliver responding to the community, it has great value. I feel frustrated when people dismiss the very real benefit of cooperative context switching as irrelevant to them.
Why accept a library which is over-engineered for the advertised use case (see above) and not (yet) fit for the broader one? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu