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

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

N3711 
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3711.pdf> 
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
N3533 
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html> 
C++ Concurrent Queues

Have you tried to follow the same interface?

Best,
Vicente