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

6 Sep 2015

      ...
...
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.
This was exactly what I understood.
...
...
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> 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.
I'm sure we will reach to do it. My concern was that we can not reject a
Le 06/09/15 17:20, Hartmut Kaiser a écrit :
library because it doesn't solves this still unresolved issue.
...
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.
Other alternatives could be:
Having an overload that has the FUTURE type constructor  .

namespace std // *1
{
      template  *2
          requires(is_future<Future>)...
      apply> when_all(Future &&... f) // *3
      {
          (await f)...;
          return make_tuple(std::forward<Future>(f)...);
      }
}

*1 on single definition on std
*2 Has an additional template parameter the future type constructor
*3 apply, T> is future<T>
future<_> specialization with a plaeholder can be seen as a future type 
constructor.

The usage

auto r = std::when_all>(f1, ... fn);

Alternatively the function could also deduce the result from the first 
future.

Vicente

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

Vicente J. Botet Escriba