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

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-23 10:50:47

Frank Mori Hess wrote:
> 
> How about an additional future_select overload which accepts two 
> boost::shared_container_iterators as arguments, and returns a 
> future<shared_container_iterator>?  The returned iterator would point at
> the 
> future which is ready or has an exception.  Then the caller could use the 
> returned iterator to erase the element from the container before calling 
> future_select again.  The shared_container_iterator would insure the input 
> container of futures doesn't die before the return future becomes ready.
> 

That would restrict users to put their futures in a container created as a
shared_ptr, right? Williams' shared_future already has reference semantics
and could be copied. unique_futures should somehow be moved in and owned by
the composite future as nobody else should look at it's result. Not sure
what is best here.

Frank Mori Hess wrote:
> 
> Having a future execute a callback at the end of a wait completing seems
> only 
> marginally useful to me.  I'm not sure it's worth the complication.
> 
> - snip -
> 
> That's exactly what poet::active_function does, or did you have something 
> different in mind?
> 

Yes, I'm thinking of a passive function which doesn't have an internal
thread associated with it. One that is evaluated lazily as soon as someone
is interested in it.

I think this could be very useful, do you? I haven't worked very much with
active objects so your 5 cents are probably worth more than mine :) But yes,
it requires some complexity - probably comparable to that of
active_function.

Johan
-- 
View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29-tp16600402p17427313.html
Sent from the Boost - Dev mailing list archive at Nabble.com.