Sohail Somani wrote:
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
May I ask why you saw it necessary to have std::fork in that incarnation?
Lawrence Crowl has made an excellent point that it's important for us to support the most common use case in a simple way, even if this means that we have to sacrifice generality to do so. Hence std::fork and the simple examples.
Won't you /always/ do the same thing?
I'm not sure why we couldn't have it be implied that construction of a future implies "fork".
I didn't want to sacrifice the generality we already did have. :-) You can still make your non-blocking API (an active object, a C++ RPC interface) return a future. std::fork is merely a convenient way to use an efficient system-provided thread pool. Nothing stops you from writing your own 'fork' that doesn't, as shown in N2096.