I have been working on non-allocating future-promise which when combined with proposed expected
(i.e. basic_promise >) 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 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
then(F &&c) { return promise (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