-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov
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.
I think I get it. I suppose I was thinking along the lines of (default) allocators. I've implemented a futures-like concept that went kind of along those lines so I guess I am a bit biased :) Thanks, Sohail