I noticed that none of the "future" C++ standardization proposals by Hinnant and Dimov, as well as Sutter's Concur implicitly create a new thread upon future construction like your simple_future implementation. As far as I can tell, their future classes are very simple and almost completely agnostic to the scheduling, threading, etc particulars.
ie, the Hinnant proposal at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2094.
Braddock Gaskill wrote: In short, I completely agree with your points. But remember, the futures implementation in the vault has been written long before any of these proposals have been published, so it's just an useful experiment, even if not with optimal results. I'm personally very interested in the futures concept as well, so please count me in when it comes to any new implementations. We should try to get it as close as possible to a future standard, though. Regards Hartmut html#futures
would do the following if a new thread was needed: std::future<int> f1 = std::launch_in_thread(f);
but more likely in the real world since thread creation is expensive: std::future<int> f1 = std::launch_in_pool(f);
In the meanwhile, Sutter is on an Active Object kick: future<int> f1 = myActiveProxy.f()
I noticed that your implementation of simple_future takes a considerably different tack, where future_base is derived and typed, and the derived future sub-class itself has knowledge of how to launch the thread with the functions.
Glancing through the code, this seems to add considerable complexity and dependencies to class future, and encourages users to sub-type class future, a la simple_future.
Is there any reason task creation, scheduling, and threading can't be entirely disentangled from the future concept?
val.cancel() isn't supported at all, mainly because Boost.Thread doesn't support cancel.
Thread lifetime won't necessary (usually?) be linked to asynchronous function call lifetime. Sutter makes use of a future::cancel(), and Dimov notes "Once a thread layer and a cancelation layer are settled upon, future would need to offer support for canceling the active asynchronous call when the caller is no longer interested in it;"
Maybe this could be handled with an optional "cancel" function passed to the future constructor, like the way a custom destructor can be passed to a shared_ptr. If cancel() is a no-op for some scenarios, it could either throw or be ignored.
I have a serious need for this functionality, so I'm willing to put in a bit of effort to work up some solution.
Thanks, Braddock Gaskill Dockside Vision Inc
The documentation is incomplete except for the simple case, which appears to spawn a new thread for every new future?
Yes.
The ability to use a future with the asio::io_service in
particular
would be quite powerful.
Agreed. And I'm happy to assist, if needed.
Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost