Re: [boost] Review Request: future library : what does future of references exactly means?

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-12 17:44:23

----- Original Message ----- 
From: "Johan Torp" <johan.torp_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, May 12, 2008 12:14 PM
Subject: Re: [boost] Re view Request: future library (N2561/Williams 
version)

> I thought the most common use case for futures was the active object
> pattern. We should all try to agree what use cases/design patterns/higher
> level abstractions are most important and which we want to support. IMHO,
> this should be top priority for the "future ambition". Even though no 
> higher
> level abstractions built on futures will make it to C++0x or boost anytime
> soon, it's important that the future interface needn't change to support
> them in the - future :)

I don't know if the most common use case is the active object pattern, I use 
it every time I call a functions whic could finish or not depending on its 
internals. Some times the function sould wait on some messages and then the 
best is to return a future. But the function can also finish on the same 
thread if it don't needs external interaction.
The client could later on wait in the future (active) or attach a callback 
to be called when the future is ready (reaction). For example:

{
    // ...
    future<T> f = call_somme_fct();
    // ...
    // when the result is needed either wait by using it or
    if (!f) // attach some callback and change the intenal state
    else // continue
    // ...
}

I agree with you that the best test for the future interface is to show some 
good usages in the tutorial and examples of the library. The threadpool 
library could be one, but not the only one.

Imagine now we had a function which returs a value and had an out parameter 
(maybe by reference)

Result f(InOut& ref);

Now we want to refactor this function (either because the new implementation 
will introduce an IO wait, or because the old blocking  implementation could 
not be supported. Which should be the interface of the new function. The 
first thing could be to try with

    future<Result> f(InOut& ref);

but nothing forbids the caller to use the ref parameter before the operation 
has completed and which could be invalid. If we want consistency what we 
would need is something like

    future<Result> f(future<InOut&>& ref);

IMO this do not works in any proposal?
Do we need future to works with in/out references?

Yet another example
    future<Out&> f();

Note that future<Out&> and future<InOut&> should not mean the same. Do we 
need two future of reference classes? future<InOut&> will need a constructor
    future<InOut&>(InOut&),
but the assocaited promise should copy the value when doint the set_value.

Any thought? Has all this a sense or I'm completly lost?

This example was there only to introdude other use cases, and in particular 
future of reference types or pointer types. If you have a better choice for 
the f function do not hesitate.

Anthony, sorry for short cut (futures instead of unique_future or 
shared_future). In order to be coherent with the thread library 
(mutex/shared_mutex), should't unique_future be named future?

Vicente