Boost logo

Boost :

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:


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:


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


    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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at