Re: [boost] [futures] boost::futures

From: Sohail Somani (s.somani_at_[hidden])
Date: 2007-03-09 18:55:39

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Braddock Gaskill

> I noticed that none of the "future" C++ standardization proposals by
> Hinnant and Dimov, as well as Sutter's Concur implicitly create a new
> thread upon future construction like your simple_future 
> implementation. 
> As far as I can tell, their future classes are very simple and almost
> completely agnostic to the scheduling, threading, etc particulars.

You are right. The idea is to be able to scale to whatever the node can
handle.

So 100 futures on a single processor node would probably not execute in
100 threads(!)

> Is there any reason task creation, scheduling, and threading can't be
> entirely disentangled from the future concept?

Maybe not entirely, but at some point the future would probably tell
some "future scheduler" to schedule the future. I think this is as far
as the futures concept should know about scheduling or threads (i.e.,
not much!)

> > val.cancel() isn't supported at all, mainly because 
> Boost.Thread doesn't
> > support cancel.
> 
> Thread lifetime won't necessary (usually?) be linked to asynchronous
> function call lifetime.  Sutter makes use of a 
> future::cancel(), and Dimov
> notes "Once a thread layer and a cancelation layer are settled upon,
> future would need to offer support for canceling the active 
> asynchronous
> call when the caller is no longer interested in it;"

I think the real power of futures is in future groups, which would
require thread cancellation. Seems like you would have to modify the
worker code to either tell the API that you are cancellable or to check
if you've been asked to be cancelled. I think an API would be ideal
which is probably what Dimov is getting at.

Sohail

PS: IMVHO active objects are iffy, I like futures.