10 Mar
2007
10 Mar
'07
midnight
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov
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? 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". Thanks, Sohail