Subject: Re: [boost] Boost.Fiber review January 6-15
From: David Sankel (camior_at_[hidden])
Date: 2014-01-06 23:31:32
On Mon, Jan 6, 2014 at 6:07 AM, Nat Goodspeed <nat_at_[hidden]> wrote:
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk