On Tue, May 9, 2017 at 7:16 AM, Casey Bodley <cbodley@xxxxxxxxxx> wrote: > I recently discovered that the Boost.Thread library implements some > extensions to boost::future from the 'Technical Specification for C++ > Extensions for Concurrency' [1]. The std::experimental interfaces are > documented on cppreference.com [2], but neither gcc nor clang provide them. > > The coolest new feature is future::then(), which takes a continuation to be > called once the future is ready, and returns a future for the continuation's > result. This allows futures to be composed into higher-level asynchronous > operations - an ability that is sorely lacking in the c++11 std::future. > > While these extensions are not enabled in boost by default, they can be > turned on with a series of BOOST_THREAD_PROVIDES_FUTURE* defines (since > boost 1.57). The boost documentation for 'Conformance and Extension' > [3]describes the status of this implementation, listing some features as > 'partial'. I wrote a set of unit tests to explore this, and was happy with > the results. The only unfortunate piece missing is 'implicit unwrapping' for > future::then() - if you pass it a continuation that returns a future<T>, > then() will return a future<future<T>>. This -should- be implicitly > converted to future<T>, but boost::future requires you to do it explicitly > by calling future::unwrap(). > > I'm curious to see how people feel about this. Would you consider using > boost::futures? Are there concerns about using boost extensions? About > slight changes to interfaces? I opened a pull request [4] for discussion - > take a look at the unit tests for examples, and let me know what you think. This'll probably get more attention once Luminous is out, but we need a futures library for the OSD and if there's one in Boost (that might make it into the standard?) then it'll be an obvious candidate, assuming it's capable enough to fulfill our needs! -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
