The mini-review of Boost.Fiber by Oliver Kowalke ran from Friday
September 4th through Sunday September 13th. There was lively
discussion, but only two actual reviews:
Agustín K-ballo Bergé: not yet (list of issues below)
Niall Douglas: yes, plus suggestions (below)[0]
In addition I received two "review withheld" notes:
Vicente J. Botet Escriba wanted me to address the previous review
point by point. That seems like a reasonable request, and I apologize,
but I too have time pressures.
Giovanni Piero Deretta made suggestions (synopsized below) with the
statement that he will make a recommendation when he sees the library
author's progress along those lines.
While in theory these results might seem like a hung jury, the very
paucity of formal reviews supports a cautious approach.
The verdict is: not yet, with specific points as noted below.
No reviewer explicitly designated specific points as being essential.
(Niall Douglas explicitly designated his suggestions as post-adoption
enhancements.)
I have made an attempt to rank the recommendations received in
descending order of importance to the community. My criteria are:
Robustness: does lack of this request pose significant risk to a
consuming program?
API stability: could this request be considered an implementation
detail, or would the change break early adopters?
Demand: how many people requested the same thing?
If you feel that I have misrepresented the importance of one of your
points (or omitted something entirely), please respond. Ultimately, of
course, the importance of any given point to the community at large
will be reflected in the next mini-review.
-----------------------------------------------------------------
Requests:
Cross-thread fiber migration: Evidently the community strongly desires
the ability to transfer a suspended fiber from one thread to
another.[1] Of course there must be controls. Migration might be
explicit; but if implicit, there must be a way to designate which
fibers may and may not be migrated. An RAII class that temporarily
disables migration would also be desirable -- for instance, to
guarantee TLS consistency for some specific period.
Cross-thread migration support implies a requirement to document the
thread safety requirements of the customization API.
Standard required timing specifications: meet (30.2.4 Timing
specifications [thread.req.timing]).
Adapt one or more existing test suites for thread facilities to
validate the correctness of the Fiber library's synchronization
constructs: e.g. from libc++, libstdc++, Boost.Thread, HPX.
std::chrono support: ensure that wait_until() can accept any supported
time_point specialization. (The library author asserts that this has
already been fixed on the 'develop' branch.)
C++11 compatibility: Agustín K-ballo Bergé volunteered to help with
this point post-adoption. Paul Fultz offered fit::capture to emulate
C++14 move capture.
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.
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.
Avoid holding mutex during condition_variable::notify_*() calls. (The
library author asserts that this has already been fixed on the
'develop' branch.)
packaged_task must not decay-copy its task arguments.
Align fibers::async() signature, result description and invoke_helper
implementation with std::async(). Avoid returning std::move(...).
Wait list implementation: try an intrusive linked list of fiber_context objects.
Avoid sleeping thread when no fibers are ready -- block on external
event. Better handling of waiting tasks (decentralized wait queues?).
Optimization to resume awakened fiber on the thread that awakens it.
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.
Leverage predicate-based condition::wait() overload internally.
Nested schedulers: make schedulers be schedulable entities themselves.
Improve robustness of `promise' handling in Asynchronous Callbacks
documentation. Avoid overconfident remarks about it.
Fix Note overstating the requirements on condition_variable::wait().
The discussion also surfaced the desirability of Grand Unified Future
Theory, but it was generally agreed that this is out of scope. Put
differently, it would be unreasonable to put the onus on Fiber to
solve that very broad cross-library problem.
Many thanks to all participants, and thanks especially to Oliver
Kowalke for all his work on this library!
Nat Goodspeed
Boost.Fiber Review Manager
________________________________
[0] Niall Douglas snuck his review recommendation into the following
mail message:
http://lists.boost.org/Archives/boost/2015/09/225228.php
(second to final paragraph). His suggestions were in private mail.
[1] Giovanni Deretta suggests that it might be possible to allocate --
without actually running -- an actual kernel thread per fiber, simply
to give each fiber its own TLS area.
