Re: [boost] future/packaged_task Sean Parent design

Subject: Re: [boost] future/packaged_task Sean Parent design
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-06-24 13:45:29

Le 24/06/15 11:13, Niall Douglas a écrit :
> 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.
Why do you mix any discussion about futures with 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.
You could have a packaged_task that just acts as a promise. The single 
difference is the interface.
> There are even times you just want to create a future standalone, and
> for that we now have make_ready_future().
Agree for make_ready_future/make_exceptional_future. This is not 
incompatible with Sean design.
>
>> 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.
std::future has always some kind of shared_ptr to the shared state. The 
share nature on shared_future is related to the fact that the value can 
be read several times.
> 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.
Why? because it uses heap memory?
>
>> Scales better. IIUC the implementation allows to implement when_all on
>> top of future/packaged_task. The trick is that that the packaged_task
>> can store some context.
>>
>> async has always an Scheduler as parameter.
>> Scheculers are just Copyable Callables having this signature
>> void(void()). There is no need for function add/spawn.
>>
>>
>> when_all has also a callable as argument.
>>
>> I find the Sean's design clean and simple (See the code [2]). What do
>> you think of it? Do you see any issues on it?
> I think it's very easy to do a beautiful design that trades off
> performance for a beautiful design.
Where do you see there are performances issues that can not be fixed 
without changing the interface, that is that are not QOI.
> I also think you can design a
> system which has poor low wait object performance but excellent high
> wait object performance, and vice versa. The problem to be solved is
> what balance between the two is best for most users of your design.
Where do you place the std::future design, the Sean's design and why not 
your design respecto the the previos clasification?
>
> In the future-promise I am currently building, I always ask this
> question when thinking about a potential feature or design:
>
>     "Will this future-promise be lightweight enough to promise on
> every single SHA256 round in a hash?"
>
> That's about 400-500 cycles per SHA256 round, so I want
> future-promise construction, set_value and promise destruction to fit
> into a budget of about twenty CPU cycles.
>
> I don't know if I'll achieve that, but that's my design goal. I want
> future promise to become really lightweight. shared_future will
> remain heavy for those who need it.
Do you mean shared_ptr?
The best when talking about performance is to have some figures :)
>
>> * I don't understand why when_all continuation has the futures as
>> parameters (I suspect that this is a type on the documentation).
>> * I would rename get_try to try_get. This function could return
>> optional<expected<T>>.
>>
>> What are you missing ?
>> * catch_error/recover that is already planed.
>> * when_any
> I'd like to see any proposed C++ task system integrate well with
> ASIO. Tick that box for me and I am interested. Eliminate memory
> allocation and exception_ptr from the future-promise cycle and I am
> very interested indeed.
>
>
Good luck with your non-allocating future design.
Vicente