Re: [boost] Re view Request: future library (N2561/Williams version)

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-05-25 16:51:37

On Sunday 25 May 2008 14:02, Peter Dimov wrote:
> Here's one way:
>
>     future<T> ft;
>
>     for( int i = 0; i < n; ++i )
>     {
>         ft = ft || async( f, i );
>     }
>
>     T t = ft.get();

That reminds me, I've been so focused on trying to make future_select work 
with heterogeneous input futures, that I neglected the homogeneous case.  
That is, future_select() always returns a future<void> even when all the 
input futures have the same type.  And after all, maybe supporting the 
homogeneous case is good enough.  For example, in my use case I've already 
taken care to type-erase the method requests in the schedulers down to a 
uniform type, because the scheduler needs to store them in a container 
anyways.

So the only other thing I'd need is some kind of explicit future container 
that can be re-used to "wait for any" repeatedly without rebuilding the 
entire set of futures each time.  Maybe something with a queue-like 
interface:

template<typename T>
class future_selecter
{
public:
        future<T> front();
        void pop();
        void push(const future<T> &f);
};

where the future returned by front() would have the value from the next 
future in the future_selector to become ready.  pop() would discard the 
completed future previously being returned by front(), so front() can 
return a new future corresponding to the next one to complete.