Re: [boost] Boost.Fiber review January 6-15

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2014-01-07 02:19:15

2014/1/7 David Sankel <camior_at_[hidden]>

> 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
   ...
}