[cpp-threads] Asynchronous Function Proposal

[Oliver Kowalke]

> However, I did get a suggestion from Jeffrey Yasskin to make the
> policy object more visible.  Something like...
> 
> int parallel_sum(int* data, int size)
> {
>   int sum = 0;
>   if ( size < 1000 )
>     for ( int i = 0; i < size; ++i )
>       sum += data[i];
>   else {
>     std::async_policy_whatever policy_obj;
>     auto handle = std::async(policy_obj, parallel_sum,
>                              data+size/2, size-size/2);
>     sum += parallel_sum(data, size/2);
>     sum += handle.get();
>   }
>   return sum;
> }

This is similiar to what boost.task currently provides.
Only the policy (== async. executor) doesn't not take care of the returned handle so that the policy can be reused for multiple invokations with async().
The behaviour of the handle depends on the policy == if the policy spawns a new thread then handle calls thread::join() in its destructor. If the policy submits the task to a thread-pool, handle doesn't care because the threads are joined by the pool (N2880). 

 
> >  - We shouldn't propose a third future type. This one should
> >    return unique_future (and that and shared_future should be
> >    fixed if deemed necessary). Note that this fixes a usability
> >    issue with the current proposal, namely that the user can't
> >    put the result in a shared_future if copying is required.
> 
> Can you provide a use case for why this flexibility is helpful?
> After all, the original call was single-point as well.

Why not introduce another object returned by async() - because the current proposal doesn't provide thread-interruption (as boost.thread does) but maybe later the users require cooperative-task interruption.

I think if this is desired it does not belong to the domain of futures (which is a proxy for a result that is initially not known).

Oliver

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01