On Mon, Jan 6, 2014 at 6:07 AM, Nat Goodspeed
Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively.
A few questions and a few comments... What are the most typical use cases for a fiber library? Were any alternatives to the following behavior? If there were, what were the benefit/drawback tradeoffs that led to this decision? { boost::fibers::fiber f( some_fn); } // std::terminate() will be called What happens operationally to a detached fiber? Will it ever continue execution or is it for all practical purposes destroyed? Did you consider making algorithm specific fiber members, such as 'thread_affinity' and 'priority', controllable via. template arguments for threads? If I wanted to create a new scheduler algorithm that required per-fiber information, how would I implement that with this library? Did you consider giving some more explanation or code for the publish-subscribe application? It was a bit difficult to follow that example without knowing what reg_ and cond_ were. I love the functionality provided by 'fiber_group'. I like the convenience of the heap allocated default scheduler as an alternative to a defaulted template parameter (like std::vector's allocator). Best Regards, David Sankel