From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-12 17:44:23
----- Original Message -----
From: "Johan Torp" <johan.torp_at_[hidden]>
Sent: Monday, May 12, 2008 12:14 PM
Subject: Re: [boost] Re view Request: future library (N2561/Williams
> 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
> 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
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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk