[cpp-threads] RE: "Agenda" for august 23-25 concurrency meeting

[Howard Hinnant]

On Aug 31, 2006, at 4:08 PM, Lawrence Crowl wrote:

> On 8/31/06, Howard Hinnant <hinnant at twcny.rr.com> wrote:
>> The question I put before us, and strongly recommend that we answer
>> positively is:
>>
>>      For asynchronous function calls, do we offer some mechanism for
>>      O(1) performance
>>      of the return type as we do for synchronous function calls?
>>
>>      thread<vector<int> > t = launch_thread(bind(compute, input  
>> data));
>>      vector<int> v = t();  // is this ridiculously expensive?
>
> I don't see how we have much choice but that the return is  
> expensive in
> some cases.  Certainly move semantics can help, but the core problem
> is the final destination may not have had its storage allocated at  
> the time
> the thread computes the result.  To pick a more obvious example,
>
>    struct huge { int array[10000]; };
>    thread<huge> t = launch_thread(bind(compute, input data));
>    .... delay longer than compute ....
>    huge v = t();

<nod> Agreed.  Let's just not unnecessarily penalize those types that  
*are* cheaply returnable.  I.e. neglecting the cost of thread  
launching/joining, it should not be significantly more expensive  
(orders of magnitude) to call a function asynchronously than  
synchronously (at least at certain level in the threading API).

I feel the need to hammer this point home because we've all been  
educated over the past decade that returning a vector from a function  
is an O(N) operation and that's just a fact of life.

      Returning a vector from a function is no longer an O(N) operation.

Let's make sure we don't have to add: unless you call it asynchronously.

But I can live with:  unless you call it from a future so that you  
can hand out multiple copies of the return.

And lets not forget returning non-copyable types:

Now you can say:

      std::fstream foo();

I don't want to add: unless you call it asynchronously.

-Howard