Re: [boost] Non-allocating future-promise

Subject: Re: [boost] Non-allocating future-promise
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2014-10-17 17:07:39

> I have been working on non-allocating future-promise which when
> combined with proposed expected<T, E> (i.e. basic_promise<expected<T,
> E>>) will provide a close substitute to std::future/promise, except
> that it doesn't use an allocator and can reduce to pure constexpr
> when possible e.g. this code:
> 
> __attribute__((noinline)) int test1()
> {
>   promise<int> p;
>   auto f(p.get_future());
>   p.set_value(5);
>   return f.get();
> }
> 
> ... reduces to exactly:
> 
> _Z5test1v:                              # @_Z5test1v
> 	.cfi_startproc
> # BB#0:                                 # %_ZN7promiseIiJEED2Ev.exit2
> 	movl	$5, %eax
> 	ret

That's cool! I assume all of the necessary synchronization is done
lock-free?

> The non-allocating future-promise is intended to be compatible with
> the Concurrency TS extensions
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4123.html)
> where futures can have continuations scheduled against them via a
> future.then(callable). However, this involves an unavoidable memory
> allocation, which while fine for dynamically assigned continuations
> is overkill for statically assigned continuations.
> 
> There is no reason why one could not also have a method of statically
> adding continuations which uses type extension to store the
> additions. Let us say we have a template<class T, class...
> Continuations> class promise and that this promise also provides a
> .then(callable) like this:

FWIW, N4123 adds .then to the future<> type, not the promise<>. I don't
think it makes a lot of sense to add it to the promise in the first place as
continuations are something local to the consumer, not the producer.

> 
> template<class F> promise<T, Continuations..., F> then(F &&c)
> {
>   return promise<T, Continuations..., F>(std::move(*this),
> std::forward<F>(c));
> }
> 
> ... and therefore to statically add continuations to the future
> promise, one simply iterates .then(callable) on the promise like
> this:
> 
> auto p=promise<int>().then([]).then([]) ...;
> auto f=p.get_future();
> p.set_value(5); // executes all the continuations
> 
> My first question to the Boost community is this: is there some less
> ugly way? I'm thinking maybe the promise's constructor could take a
> set of continuations, and then a make_promise(callable, callable,
> ...) could construct a statically continued future-promise?

You seldom want to chain .then() calls, in my experience. Most of the time
to attach one continuation and pass the resulting future to some other place
where you might attach another continuation, etc.

> My second question to the Boost community is this: should static
> continuations be able to see the value being set? Or indeed, to
> modify it before it gets sent to future.get()?

What would be the point of having a continuation which does not see the
value once set?

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