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

From: Braddock Gaskill (braddock_at_[hidden])
Date: 2007-03-09 18:30:22

On Fri, 09 Mar 2007 13:57:52 -0600, Hartmut Kaiser wrote:

>> Can I use it in conjunction with my own thread pool or with 
>> an active object?
> 
> If you write the thread pool or active object support, certainly. The
> library as is doesn't know anything about thread pools or active objects. It
> just spawns a new thread for every future. 

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
>