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