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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-09-06 11:40:54

Le 06/09/15 17:20, Hartmut Kaiser a écrit :
>> 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<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.
I'm sure we will reach to do it. My concern was that we can not reject a 
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 <typename FutureTC, typename Future...> *2
          requires(is_future<Future>)...
      apply<FutureTC, tuple<Future...>> 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<future<_>, T> is future<T>
future<_> specialization with a plaeholder can be seen as a future type 
constructor.

The usage

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

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

Vicente