Boost logo

Boost :

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
allocator).

Best Regards,

David Sankel


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk