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

[Peter Dimov]

Howard Hinnant 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?

Is

future< vector<int> > fv = ex.execute( bind( compute, input data ) );
vector<int> v = fv.move(); // second move() or subsequent op() throws 
value_already_moved

good enough? It'd work for any asynchronous function call, not just a 
dedicated thread, but the syntax is a bit clumsier (and the implementation 
somewhat fragile but doable.)

> We can have both (copyable) futures and efficient mechanisms for
> returning heavy values from threads.  We do not have to lock our
> customers into one design or the other in this engineering tradeoff.

Yes, but... providing two separate and similar mechanisms that essentially 
do the same thing would be confusing. Moreover, I really wouldn't want us to 
repeat the boost::thread::join "call exactly once or suffer undefined 
behavior" mistake. A threading API should appear sequentially consistent and 
join/wait/operator() ought to be idempotent and race-resilient. Explicitly 
labelling the .move operation can be considered a feature in this regard.