On 9/4/2015 12:14 PM, Nat Goodspeed wrote:
Hi all,
The mini-review of Boost.Fiber by Oliver Kowalke begins today, Friday September 4th, and closes Sunday September 13th. It was reviewed in January 2014; the verdict at that time was "not in its present form." Since then Oliver has substantially improved documentation, performance, library customization and the underlying implementation, and is bringing the library back for mini-review.
The substance of the library API remains the same, which is why a mini-review is appropriate.
The section "Integrating Fibers with Asynchronous Callbacks" contains the following snippet: boost::fibers::promise< AsyncAPI::errorcode > promise; boost::fibers::future< AsyncAPI::errorcode > future( promise.get_future() ); // We can confidently bind a reference to local variable 'promise' into // the lambda callback because we know for a fact we're going to suspend // (preserving the lifespan of both 'promise' and 'future') until the // callback has fired. api.init_write( data, [&promise]( AsyncAPI::errorcode ec){ promise.set_value( ec); }); return future.get(); The comment is not entirely accurate, as there is a potential for the destructor of `~promise` to start executing before `promise::set_value` has returned (crashes due to this usage have been spotted in the wild). Unlike `std::condition_variable` and the upcoming `std::latch`, `std::promise` has no such guarantee nor `fiber::promise` documents it. Instead of documenting it (your current implementation does indeed look safe), I'd suggest to use an idiom that would behave well with `std::promise`, `boost::promise` and `whatever::promise` too: [promise = std::move(promise)]... And simply drop the misleading remark. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com