> -----Original Message-----
> From:
boost-bounces@...
> [mailto:
boost-bounces@...] 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
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
