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

From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2007-03-09 19:23:23

Braddock Gaskill wrote:

In short, I completely agree with your points. But remember, the futures
implementation in the vault has been written long before any of these
proposals have been published, so it's just an useful experiment, even if
not with optimal results.

I'm personally very interested in the futures concept as well, so please
count me in when it comes to any new implementations. We should try to get
it as close as possible to a future standard, though.

Regards Hartmut

> 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.
> 
> ie, the Hinnant proposal at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2094.
html#futures
> would do the following if a new thread was needed:
> std::future<int> f1 = std::launch_in_thread(f);
> 
> but more likely in the real world since thread creation is expensive:
> std::future<int> f1 = std::launch_in_pool(f);
> 
> In the meanwhile, Sutter is on an Active Object kick:
> future<int> f1 = myActiveProxy.f()
> 
> I noticed that your implementation of simple_future takes a 
> considerably different tack, where future_base is derived and 
> typed, and the derived future sub-class itself has knowledge 
> of how to launch the thread with the functions.
> 
> Glancing through the code, this seems to add considerable 
> complexity and dependencies to class future, and encourages 
> users to sub-type class future, a la simple_future.  
> 
> Is there any reason task creation, scheduling, and threading 
> can't be entirely disentangled from the future concept?
>  
> > 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;"
> 
> Maybe this could be handled with an optional "cancel" 
> function passed to the future constructor, like the way a 
> custom destructor can be passed to a shared_ptr.  If cancel() 
> is a no-op for some scenarios, it could either throw or be ignored.
> 
> I have a serious need for this functionality, so I'm willing 
> to put in a bit of effort to work up some solution.
> 
> Thanks,
> Braddock Gaskill
> Dockside Vision Inc
> 
> 
> > 
> >> The documentation is incomplete except for the simple case, which 
> >> appears to spawn a new thread for every new future?
> > 
> > Yes.
> > 
> >> The ability to use a future with the asio::io_service in 
> particular 
> >> would be quite powerful.
> > 
> > Agreed. And I'm happy to assist, if needed.
> > 
> > Regards Hartmut
> > 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost