On Wed, Jun 24, 2015 at 12:09 AM, Vicente J. Botet Escriba
Hi,
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.
Yes, packaged task is a far better producer side interface than a naked promise. I like the idea of creating the future and promise (or better, packaged_task) together, although my preference would be a way to create the packaged task from the future, which opens a lot of optimiation opportunities (for example if the future is non copyable non movable, no memory allocation is required).
His future library doesn't include a shared_future as the future contains a value that can be observed several times.
This is my biggest issue with Sean's design. Sharing the state among multiple consumes pretty much requires heavy weight synchronization. But see below.
The continuation takes the value and not the future. So a future can have several continuations.
What's the thread safety guarantees of future? 'As safe as int' or, for example, concurrent calls to .then are allowed? If the former, a copy could be a real deep copy (a new shared state is allocated and broadcasting is internally done via 'then'). That's not how Sean future is currently implemented though.
If the store type is movable only, then the future can have only one continuation. Not really strange coming from Sean, future and packaged_task are copyables :) One more thing, there is not get no wait, but a get_try that return an optional<T>.
Intresting, so if a consumer needs wait must implement it on top of then. This is fine, but you need a way to unregister a 'then'.
Scales better.
the interface is certanly nicer and simpler, but why do you think it scales better? [...]
What are you missing ? [...]
The when_any continuation probably needs to be passed the all the futures instead of just the value that is ready, so that it can be called recursively. when_any also requires the ability to unregister a continuation from a future, otherwise if called 'in a loop' the number of continuations associated with futures will grow. Implementing this eficiently is not trivial. -- gpd