From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-09 19:10:06
Sohail Somani wrote:
>> Indeed, the intent has been for futures to support arbitrary
>> 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
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk