Re: [boost] [futures] boost::futures

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
>> 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
>
> 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.