On 24 Jun 2015 10:11 am, "Niall Douglas"
On 24 Jun 2015 at 1:09, Vicente J. Botet Escriba wrote:
Sean Parent suggests (See [1] Better Code: Concurrency) to remove the promise and left the packaged_task serve as single provider of a future. Both are created at once using the package factory.
I was at his talk at C++ Now.
The first thing which put me off his proposal was that he appears to be unaware of the highly optimised and very flexible de facto task concurrency system in C++ which has been around for years, and has just recently been standardised. It's called ASIO.
I also think packaged_task is overkill for creating futures. There are some times you really do just want a promise and nothing more.
There is no reason for a packaged task implementation to be more heavy weight than a promise. If the packaged task is [](T x) { return x; } then it is also semantically equivalent to promise<T>, just in a nicer interface. Bonus points it works beautifully with ASIO without any explicit support from ASIO itself.
There are even times you just want to create a future standalone, and for that we now have make_ready_future().
His future library doesn't include a shared_future as the future contains a value that can be observed several times.
If I remember rightly, internally his future has a shared_ptr, which really means he's proposing that future becomes a shared_future. I had doubts before until that part, but that killed his proposal for me. It's a non-starter as a practical design for my needs, but is still useful for ideas.
His implementation uses a shared ptr, but I think you could do without by deep copying the futures and internally chaining via then. This way you only pay the cost if you actually copy. I strongly believe that 'then' and other accessors should be non const so that concurrent calls *on the same future* need not be supported. -- gpd