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.