From: Braddock Gaskill (braddock_at_[hidden])
Date: 2008-04-13 18:33:09
On Thu, 10 Apr 2008 21:53:33 +0200, vicente.botet wrote:
> How do your library positions with respect to the standard proposals?
> N2561 Anthony Williams: An Asynchronous Future Value
I've now taken a good look at the recent C++0X N2561 "An Asynchronous Future
Value" proposal.
Both my library and N2561 are heavily based on Peter Dimov's earlier API... I
dare say a few method name changes would make N2561 a proper subset of my
future and promise classes and future_wrapper helper.
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.
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). add_callback is a hook called when the future is fulfilled. End users probably shouldn't have to touch it, but framework authors (who write schedulers, asio, co-routines, etc) will DEFINITELY need it. add_callback() enables the following: -Future Operators ((f1 && f2) || (f3 && f2) etc) - With add_callback, custom future_operators can be written by users. -Guarded Schedulers (See my library doc "Future Concept Tutorial" section at http://braddock.com/~braddock/future) - Guards are a fundamental concept in the academic future languages I've studied (see some of Ian Foster's papers on Strand and PCN, for example). I have found you can do some amazing things with a guarded task scheduler (I've implemented one outside the future lib). -Basic "future fulfillment" event notification (ie, just use add_callback as an event handler). Gives you essentially a signals/slot capability. Not a fan. An alternative to add_callback() would be to provide just the operators themselves - Guards can reasonably be derived from the combination ops. Any of these mechanisms solve the busy wait in the N2561 motivating example. -- 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. Again, see my library doc Tutorial where I show how to easily create a "Lazy Job Queue". Permits nice Memoization patterns as well. Lazy Futures are also needed for "Lazy Future Streams". A Stream is the primary means of inter-task communication in future-related academic languages. It permits producer/consumer patterns and one-to-many channels. A Lazy stream allows the producer task to produce new items only as fast as his fastest consumer needs them (See Ian T. Foster's work again - or my test_future.hpp unit test code). Note I provide an easy-to-use future stream library with std iterator interface. I also provide a future::cancel(), which has been discussed in the other posts and which I'm not terribly attached to. I really like seeing the N2561 C++ proposal uses a split future/promise. Broken_promise exceptions have saved me many times in real-world applications. And I like that you aren't using the implicit type conversion (which has bitten me many times in real-world applications! I only use my future::get() method now). (I still provide implicit conversion, but would take it out very fast if others are no longer attached to it). Braddock Gaskill