-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Braddock Gaskill
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.
You are right. The idea is to be able to scale to whatever the node can handle. So 100 futures on a single processor node would probably not execute in 100 threads(!)
Is there any reason task creation, scheduling, and threading can't be entirely disentangled from the future concept?
Maybe not entirely, but at some point the future would probably tell some "future scheduler" to schedule the future. I think this is as far as the futures concept should know about scheduling or threads (i.e., not much!)
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;"
I think the real power of futures is in future groups, which would require thread cancellation. Seems like you would have to modify the worker code to either tell the API that you are cancellable or to check if you've been asked to be cancelled. I think an API would be ideal which is probably what Dimov is getting at. Sohail PS: IMVHO active objects are iffy, I like futures.