Re: [boost] Common future base class (was Re: Boost.Fiber mini-review September 4-13)

Subject: Re: [boost] Common future base class (was Re: Boost.Fiber mini-review September 4-13)
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-09-06 11:20:36

> Le 06/09/15 15:14, Hartmut Kaiser a écrit :
> >> The problem exist already for any library proposing a standard future
> >> implementation. How can this new implementation works with a standard
> >> implementation. This is the case for Boost.Thread, HPX, Boost.AFIO,
> >> Boost.Fiber, or your own implementation.
> >> What I meant is that we need to change the standard to be able to solve
> >> this problem, as the standard don't take it in account.
> > I believe the solution to is not so much to change (std::)future, but to
> > push forward 'await' instead. It already has (most) of a
> > future-type-agnostic synchronization mechanism specified.
> You said (most). What is missing yet?

Await is assumed to return the value represented by the awaitable expression
(see below). This would not work for unique futures.

> > Granted, the
> > proposal will change, but I'm certain it will get into C++ in the C++17
> > timeframe. The 'await' allows to rewrite when_all, etc. such that it
> works
> > for any combination of input futures. Here's a sketch (sans decay,
> etc.):
> >
> > namespace foobar
> > {
> >      template <typename Future...>
> >          requires(is_future<Future>)...
> >      future<tuple<Future...>> when_all(Future &&... f)
> >      {
> >          (await f)...;
> >          return make_tuple(std::forward<Future>(f)...);
> >      }
> > }
> Clever and simple, await and variadic expansion allows this simple
> implementation for boost::wait_all. Does this work already?
> 
> This includes already a change to the standard, as when_all must work
> for any FUTURE like and off course needs await to make it simple
> 
> Have you also a clever and simple implementation for when_any? Wouldn't
> it need more changes to the standard?
> These is what I have in mind when I said "the standard don't take it
> into account " at least not now.

I understand and I agree, this needs to be solved.

Well, there is more, I actually cheated a bit. Await is currently
invalidating unique futures, so the above would work for shared_future only.
But you got the idea. I'm sure it can be done.

Wrt when_any - I don't have an idea how to properly implement that using
await at this point. The current proposal has no way of 'cancelling' await,
iirc - at least not without setting an exception.

> > i.e. every library which exposes its future type provides this trivial
> > implementation of when_all(), etc. It can consume any future from any
> other
> > place, however.
> Ok, so the user choose the future result by using a specific qualified
> overload, isn't it?
> 
> auto r = foobar::when_all(....)
> 
> Even if the implementation seems simple, it is weird to have to do it,
> but I could live with that.

I don't see any other way. Even if we find a way to customize std::future
(or its shared state) it will still have to represent (probably type-erased)
a specific implementation type (synchronization-wise) in each specific
context, which has to be specified in some way.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu