Braddock Gaskill wrote:
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.
Indeed, the intent has been for futures to support arbitrary asynchronous task execution, not just the simple thread per task model. One could imagine using futures over an interprocess protocol or TCP/IP. My current proposal for std::future<R> is available at http://www.pdimov.com/cpp/N2185.html and will be part of the pre-meeting mailing. We'll see how it fares. As an aside, does anyone have a success story about active objects? I can't seem to grasp their significance; in particular, how are they supposed to scale to many cores/HW threads if every access is implicitly serialized?