2014/1/9 Agustín K-ballo Bergé
boost::thread has a constructor taking attributes too, this is the first argument so there would be no collision.
This should be adjusted not only to be coherent with boost::thread, but
also to implement the general constructor since matching the same semantics otherwise is tricky. Consider:
boost::fiber fib{ [f = std::move(f), a0 = std::move(a0), ...]() mutable { std::move(f)(std::move(a0), ...); }; }
against the standard conformant constructor with the same semantics:
boost::fiber fib{std::move(f), std::move(a0), ...};
OK - agreed, it should be too complicated to add it
I understand the perceived convenience of semantic sugar, to me it is an unnecessary divergence from std/boost::thread.
However, I can always avoid their use completely. it could be removed but if found it useful in the case of fiber-stealing, e.g. boost::fibers::fiber f( other_rr->steal_from() );if ( f) { // migrate stolen fiber to scheduler running in this thread rr.migrate_to( f); ... } of course, I could let steal_from() return a bool Please add reference documentation for fiber::id.
OK
- There is no indication whether the futures support void (I assume they
do) and R& (I assume they don't).
future supports future< R >, future< R & >, future< void > - the problem was how to express it in a comfortable way in the docu
- The documentation for promise doesn't seem to support void, it is
unclear whether they support references. Another explicit operator bool.
promise supports promise< R >, promise< R& >, promise< void > - suggestions how to write the docu without repreating the interface for the specializations?
Refer to the standard for a concise definition of future/promise. It basically defines the specializations only when they differ.
I've had tried something like http://en.cppreference.com/w/cpp/thread/futurebut I wasn't satisfied with the result from quickbook-generated html. I'll follow your advice.