Re: [boost] Re view Request: future library (Gaskill version)

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-06 07:33:25

I've downloaded and started looking at your implementation. Well actually, I
already use a part of it in my job :)

Please disregard my previous reply - I realize now we don't want to require
users to have access to the promises to create compound futures.

Braddock Gaskill-2 wrote:
> 
> I'm disregarding the future C++ move semantics, of course.  
> We need a future<C++0x>::wait() for that... :)
> 
> unique_future<T> is an interesting concept.  Still wrapping my head around
> that.
> 

Still, boost::future might be a too general name if we believe C++0x
will provide both a reference semantics and a move semantics future object.

Braddock Gaskill-2 wrote:
> 
> My base classes offer two features which N2561 does not (and which I would
> really hope to see in any C++0X standard).
> 
> 1) First - future<T>::add_callback(f).  
> 

Exposing this in the interface poses two problems:
1. If any of the callbacks raises an exception it will be forwarded to the
promise-fulfilling thread.
2. remove_callback cannot be implemented "instantly" in a dead-lock safe
manner. User code which returns from remove_callback() will still need to be
prepared for callbacks.

I agree with you that the functionality is _very_ useful. 
Have you considered implementing a future-intrusive mechanism to wait for
multiple futures instead? This way a separate waiting thread would be needed
- but isn't that the desired use case?
You probably need to be able to wait until either any or all of a
dynamically created group of futures are ready. Future return value
composition, for instance operators && and ||, might be nice to support but
will probably require a great deal of thought.

Braddock Gaskill-2 wrote:
> 
> 2) Second - Lazy Futures.  
> 
> This is something I picked up from the Oz language future implementation,
> and
> have found very useful.  A Lazy Future essentially flags itself when it is
> "needed" - ie, when someone is blocked on a f.wait(), and f.get(), or has
> explicitly called "f.set_is_needed()".  This allows, for example, a task
> to
> only process _IF_ the result is actually needed.  
> 

Do we really want to use the future value as a parallel programming
primitive?
I haven't read about lazy future streams yet but my initial instinct is a
fear of making the future object
the solution to everything.

Introducing "is_needed" couples future-listeners and promise-fulfillers.
If I had a const promise reference I'd expect to be able to create a
temporary future, query it and then destroy it. With lazy futures, the
lifetime of futures start to matter in implicit ways which might not be
obvious to the "future using part" of the code.

Analogously I think it would be strange if a broadcaster chose to not do
something because nobody was listening or if an observable in the
observer-observable pattern changed it's behaviour if it wasn't observed.

Still, the concept might be transparent and useful enough. I need to read up
future streams and other applications some more.

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