----- Original Message ----- From: "Tom Brinkman" <reportbase@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, January 08, 2009 8:37 PM Subject: [boost] Pondering Futures
Ponderings on the Futures Library:
What is the status of Anthony Williams' submission of the futures library to the c++ standards committee?
Is it more prudent to wait to find out what the c++ standards committe is going to do first, before adding a possibly incompatible version of the futures library to boost?
One could ask, if Anthony's submission is approved by the c++ standards committe,
I think that it is already approuved.
what is the point of adding a "futures" library to boost as well?
We need it to make high level libraries, as we need a Move and Chrono library.
Is a seperate library needed? What is the advantage of having a root level library called boost::futures? Why would it not be perferable to just extend boost::thread with the additional capabiltity to handle "futures"?
The namespace has no importance. The future classes can leave on the boost namespace. Anthony even has put on the jss namesspace. I don't like to much the idea of extension without a review, but as in this case we have already an interface (that could yet evolve a little bit) the C++0x accepted interface, I think that the review could be limited to see how the current C++0x interface can be use to get other higher functionalities, Howthis interface is implemented, review the docs and the tests. Of course we can find during the review something on the current C++0x interface and semantics that it is incorrect. Anthony has added the wait_for_all and wait_for_any that uses internal modification inthe future clasess. I would like to see if these functions can be implemented from outside. Otherwise, if we can not and if we consider that these functions are necessary, this mean IMHO that the standard is not enough open. But all the if need to be proved. My question now is if we can give the same kind of functionality to the end users with another interface. I'm working' on a wait_for_all and wait_for_any that takes functions as parameters that evaluates asynchronously and return a tuple of the returned values. See (http://www.nabble.com/Is-there-any-interest-in-Asynchronous-Executors-and-As...) These functions would only use the C++0x accepted interface. The advantage of taking functions is that we can wrap these function and do something before and after, in particular signaling when the function ends so no need in this case for callback (which do not mean that we don't need callbacks for other cases). With the Anthony proposal: boost::packaged_task<int> tsk1(simple_thread); boost::unique_future<int> fut1 = tsk1.get_future(); boost::thread th1(boost::move(tsk1)); boost::packaged_task<int> tsk2(simple_thread2); boost::unique_future<int> fut2 = tsk2.get_future(); boost::thread th2(boost::move(tsk2)); unsigned res = boost::wait_for_any(fut1, fut2); int val; switch (res) { case 0: val = fut1.get(); break; case 1: val = fut2.get(); break; } // use val with my not yet completly implemented interface just that: bith::shared_launcher ae; std::pair<unsigned,int> res = bith::wait_for_any(ae, simple_thread, simple_thread2); // use res.first for the future that has finished and res.second for the value. where bith::shared_launcher is an asynchonous executor (a thread pool can also be an asynchronous executor). I have in mind also other functions as fork_all, wait_all, get_all bith::shared_launcher ae; typedef bith::result_of::fork_all<bith::shared_launcher, fusion::tuple<int(*)(),int(*)()> >::type auto_type; auto_type tple = bith::fork_all(ae, simple_thread, simple_thread); typedef bith::result_of::get_all<auto_type>::type auto_get_all_type; auto_get_all_type res = bith::get_all(tple); fusion::for_each(res, print_xml()); with C++0X this can be writes as bith::shared_launcher ae; auto tple = bith::fork_all(ae, simple_thread, simple_thread); autho res = bith::get_all(tple); fusion::for_each(res, print_xml()); I you are interested I can share with you my current implementation. Best, Vicente