Re: [boost] Updated version of futures library

From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-06-02 13:02:32

Frank Mori Hess:
> Oh, my use case is the "lifting of an ordinary function to an asynchronous 
> one
> that takes/returns future_value objects" I mentioned earlier in the post. 
> To
> be more specific:
>
> http://www.comedi.org/projects/libpoet/boostbook/doc/boostbook/html/poet/active_function.html

Hm.

It would be nice if you could provide a better motivating example. :-)

That aside, I'm not sure why you need future_value semantics. Let's assume 
that one has a primitive

    future<R> async( F f, A1 a1, ..., An an );

that schedules bind(f,a1,a2,...,an) for execution. It wouldn't be hard to 
make it recognize when Ai is future<Bi> and do the following instead:

async_with_guard(

    bind( A1::ready, a1 ) && ...,

    f,

    bind( A1::get, a1 ), ... );

The 'guard' predicate is just symbolic since the scheduler would in reality 
store the futures as dependencies and use the appropriate "multi-multiwait". 
But the point is that I don't see the above requiring any 
future_value-specific operations.

Or stated differently:

future<double> fd1 = async( f1, 0 );
future<double> fd2 = async( f1, 1 );

future<double> fd = async( f2, fd1, 0.3, fd2, 0.7 );

// actually does:

future<double> fd = async_with_dependencies(

    bind( f2,
        bind( future<double>::get, fd1 ), 0.3,
        bind( future<double>::get, fd2 ), 0.7 ), // function object

    fd1, fd2 ); // dependency list

In this case one would need to use something like protect(fd1) if the 
function really takes a future.

It's not clear whether the goal of libpoet is to provide fine-grained 
parallelism or lazy evaluation; if the latter, one could expect all 
functions to take futures, since an active_function provides no fine-grained 
laziness. In this case the above "activize by default" approach won't be 
very convenient.