2014/1/7 David Sankel
What are the most typical use cases for a fiber library?
I would say that the most use cases are task related applications (as boost.thread). The interface and classes of boost.fiber are similar to boost.thread (this was intended, you can use patterns well known from multi-threaded programming). The difference between both libraries is that a waiting thread (for instance on a condition-variable) is blocked while a fiber (waiting on a condition_variable) will be suspended while the the thread running the fiber is not (e.g. other code could be executed in the meanwhile). For instance in the context of network applications which have to serve many clients at the same time (known as the C10K problem - see http://olk.github.io/libs/fiber/doc/html/fiber/asio.html) fiber prevent overloading the operating system with too many threads while the code is easy to read/understand (no scattering the code with callbacks etc. - see example pusher-subsriber in directory examples/asio). boost.fiber uses coroutines (from boost.coroutine) internally - but boost.coroutine does not provide classes to synchronize coroutines. On the developer list some requests for such synchronization primitvies were requested which is now available with boost.fiber. Were any alternatives to the following behavior? If there were, what were
the benefit/drawback tradeoffs that led to this decision?
In the context of async. I/O (boost.asio) you could use callbacks (asio's previous strategy) but you scatter your code with many callbacks which makes the code hard to read and to follow (debugging). You could use fibers in a thread pool too - with the specialized fiber-scheduler (already provided by boost.fiber) you can implement work-stealing/work-sharing easily.
{ 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?
same as for std::thread - the fiber instance must not be joined but continues executing inside the fiber-scheduler. Did you consider making algorithm specific fiber members, such as
'thread_affinity' and 'priority', controllable via. template arguments for threads?
sorry, I don't understand your question. thready_affinity() and prioritiy() are already member-functions of class fiber - both are controlled at runtime. I don't know to which template you are referring to and the purpose to make both attributes a tempalte arg.
If I wanted to create a new scheduler algorithm that required per-fiber information, how would I implement that with this library?
deriving from interface algorithm and installing your scheduler at the top of the thread. class my_scheduler : public boost::fibers::algorithm { ... }; void thread_fn() { my_scheduler ms; boost::fibers::set_scheduling_algorithm( & ms); ... }
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 mean more comments? yes, I will! The code is similar as you would write it for threads - the difference is that the example runs in one thread (main-thread).
I like the convenience of the heap allocated default scheduler as an alternative to a defaulted template parameter (like std::vector's allocator).
the lib allocates (via new-operator) a default scheduler - if you don't want this you could simply call set_scheduling_algorithm(). void thread_fn() { boost::fibers::round_robin rr; // allocated on thread's stack boost::fibers::set_scheduling_algorithm( & rr); // prevents allocating round_robin on the heap ... }