Re: [boost] Updated version of futures library

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-06-02 14:41:09

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 02 June 2008 13:02 pm, Peter Dimov wrote:
> 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. :-)

Well, I want the "lifted" versions of functions to be as useable as ordinary 
functions.  So, you can compose functions whose types don't match exactly:

float f();
void g(double x);
g(f());	//fine

But not the version lifted to future_handles:

future_handle<float> lifted_f();
future_handle<void> lifted_g(future_handle<double> x);
lifted_g(lifted_f());	// error, no implicit conversions for future_handle

> 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.

That's interesting.  The binds you describe in async_with_guard play a role 
similar to my future_combining_barrier(), except they need a scheduler thread 
to evaluate them, whereas the user functor passed to future_combining_barrier 
will be evaluated by whatever thread tries to use the returned future once 
its future dependencies are all ready.  And as I realized and posted a couple 
hours ago, future_combining_barrier plus a future_handle would be sufficient 
for me to implement a future_value on top of.

However, the William's future does not currently support any multi-multiwait.  
Its wait_for_all and wait_for_any do not return futures but block when 
called.  The Gaskill futures do have operator|| and operator&& but they are 
not efficient enough to build a scheduler on.  So, I'd like to see something 
like the future_select, future_barrier, future_selector, 
future_combining_barrier stuff I'm working on in libpoet in the boost futures 
library.  None of them require a future_value.

> It's not clear whether the goal of libpoet is to provide fine-grained
> parallelism or lazy evaluation; 

active_function provides fine-grained parallelism.  Or, maybe 
adjustable-grained, since multiple active_functions can share the same 
scheduler thread.  Lazy evaluation can be achieved with 
future_combining_barrier (which isn't in the online docs or any release yet).

> 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.

You can get fine-grained laziness by using future_select in conjunction with 
future_combining_barrier.  For instance, if you wait on a future returned by 
future_select, and the inputs to the future select where created by 
future_combining_barrier, then it will only run the combiners of the input 
futures until the first one of them completes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIRD7G5vihyNWuA4URAsXnAJ9T2L1HVs08S2lfw4DEbEKLuj5WrwCeKSI/
ECL+rJ1JKZQeUgRl0lmuZAw=
=pw1w
-----END PGP SIGNATURE-----