Hi all, The Boost.Fiber candidate library by Oliver Kowalke begins a mini-review today, Monday May 23, which will close Wednesday June 1. It was last reviewed in September 2015; the verdict at that time was "not yet." Oliver has been working steadily to address review comments and to improve the library in other ways, and has brought the library back for mini-review. The updated documentation is here: http://olk.github.io/libs/fiber/doc/html/index.html The code is on the master branch of this repository: https://github.com/olk/boost-fiber/tree/master I believe it is Oliver's intention to respond to review feedback on the develop branch, leaving the master branch stable during the review. I will monitor reviews and discussion on both the boost-users@ list and the boost@ developers' list. Please include at least "fiber" and "review" in the subject line of your mail, e.g. by replying to this message. (Please reply to only ONE list, however.) I will also check the Boost Library Incubator for Fiber reviews: http://rrsd.com/blincubator.com/bi_library/fiber/?gform_post_id=859 though I check that less frequently than email. Please do remember to state in your review whether you think the library should be accepted as a Boost library. Thank you for your interest and your feedback! ----------------------------------------------------- Here follows a synopsis of issues raised during the September 2015 review: Cross-thread fiber migration: Evidently the community strongly desires the ability to transfer a suspended fiber from one thread to another. Now supported, with documentation. Cross-thread migration support implies a requirement to document the thread safety requirements of the customization API. Addressed. Standard required timing specifications: meet (30.2.4 Timing specifications [thread.req.timing]). Addressed. Adapt one or more existing test suites for thread facilities to validate the correctness of the Fiber library's synchronization constructs. The requester clarified in private mail that I misstated his suggestion: he wanted Oliver to review one or more such test suites to discover the kinds of issues that can arise with thread synchronization constructs. He has professed himself satisfied with the current state of the Fiber library's synchronization constructs. std::chrono support: ensure that wait_until() can accept any supported time_point specialization. Addressed. C++11 compatibility. Addressed. Document that this_fiber::yield() (et al.) are valid from main(), or in general from a thread function, as well as from explicitly-launched fibers. Addressed. Make shared_state lock requirements explicit: for example, make mark_ready_and_notify_() accept a std::unique_lock<>& (or &&) to force its caller to provide one. Addressed. Avoid holding mutex during condition_variable::notify_*() calls. Addressed. packaged_task must not decay-copy its task arguments. Addressed. Align fibers::async() signature, result description and invoke_helper implementation with std::async(). Avoid returning std::move(...). Addressed. Wait list implementation: try an intrusive linked list of fiber_context objects. Addressed. Avoid sleeping thread when no fibers are ready -- block on external event. Better handling of waiting tasks (decentralized wait queues?). Addressed. Optimization to resume awakened fiber on the thread that awakens it. Hooks provided. Template redundancy: eliminate duplication between specializations for T, T& and void. The future, shared_future, shared_state, promise and task_object templates were specifically cited. Addressed. Leverage predicate-based condition::wait() overload internally. Addressed. Nested schedulers: make schedulers be schedulable entities themselves. Not implemented. Improve robustness of `promise' handling in Asynchronous Callbacks documentation. Avoid overconfident remarks about it. Addressed. Fix Note overstating the requirements on condition_variable::wait(). Addressed.