Re: [boost] Boost.Fiber mini-review September 4-13

Subject: Re: [boost] Boost.Fiber mini-review September 4-13
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-09-07 22:12:55

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