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.
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
