Boost logo

Boost :

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

> 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, gregod at, cpdaniel at, john at