Boost logo

Boost :

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-01-08 17:48:31

Le 06/01/14 14:07, Nat Goodspeed a écrit :
> Hi all,
> The review of Boost.Fiber by Oliver Kowalke begins today, Monday January
> 6th, and closes Wednesday January 15th.
> - What is your evaluation of the design?

Hi Oliver,

glad to see that you Fibers library is under review.

I have some question related to the design.

The interface must at least follows the interface of the standard thread
library and if there are some limitations, they must be explicitly
Any difference respect Boost.Thread must also documented and the
rational explained.

std::thread is not copyable by design, that is only one owner. WHy
boost::fibers::fiber is copyable?

Why the exceptions throw by the function given to a fiber is consumed by
the framework instead of terminate the program as std::thread?

Which exception is thrown when the Error
Conditions:resource_deadlock_would_occurand invalid_argument are signaled?

Why priority and thread_affinity are not part of the fiber attributes?

The interface let me think that the affinity can be changed by the owned
of the thread and the thred itself. Is this by design?

Please don't document get/set functions as thread_affinity altogether.

The safe_bool idiom should be replaced by a explict operator bool.

Why is the scheduling algorithm global? Could it be threads specific?
BTW i sthere an exmple showing the |thread_specific_ptr trick mentioned
on the documentation. |

Why the time related function are limited to a specific clock?

The interface of fiber_group based on old and deprecated thread_group is
not based on move semantics. Have you take a look at the proposal

Task Groups As a Lower Level C++ Library Solution To Fork-Join Parallelism

Maybe it is worth adapting it to fibers.
Boost.Thread has deprecated the use of the nested type scoped_lock as it
introduce unnecessary dependencies. DO you think it is worth maintaining it?

I made some adaptations to boost::barrier that could also have a sens
for fibers. I don't know if a single class could be defined that takes
care of both contexts for high level classes as the barrier?

Boost.Thread would deliver two synchronized bounded and unbounded queue
soon based on
C++ Concurrent Queues

Have you tried to follow the same interface?


Boost list run by bdawes at, gregod at, cpdaniel at, john at