Re: [boost] [threadpool] draft n2276 - launch_in_pool

Subject: Re: [boost] [threadpool] draft n2276 - launch_in_pool
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-01-25 17:33:08

----- Original Message ----- 
From: "Dean Michael Berris" <mikhailberis_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, November 21, 2008 3:15 PM
Subject: Re: [boost] [threadpool] draft n2276 - launch_in_pool

> But I wouldn't be surprised if there would be a proposal to an
> overload to the launch_in_pool(...) method which takes a "concrete" or
> "existing" pool that is either referred to by a handle/proxy or by
> reference.
> 
> Something like:
> 
> // version 1
> template <ThreadPool pool_type, PackagedTask task_type>
> typename task_type::future_type launch_in_pool(task_type task,
> pool_type & pool) {
>  pool.post(task);
>  return task.get_future();
> }

Hi,

I'm working on a generic Asynchronous Execution framework that defines a generic fork function as 

    template< typename AE, typename Function > 
    typename result_of::fork<AE,Function >::type fork( AE& ae, Function fn );

In my approach the result of the fork depends on the Asynchronous Executor, e.g. the result of forking with tm::pool<> will be tp::task<result_of<Function ()>::type>.

Which are the minimal functions we expect from an Asynchronous Executor?
* async_call : AE, Function -> Handle<result_of<Function()>
    evaluate a function asynchronously 
* lazy_call : AE, Function -> Handle<result_of<Function()>
    evaluates a function when needed
* call_after_completion : AE, Handles, Function  ->  Handle<result_of<Function()>
    evaluates a function asynchronously after completion of all some handles

Which are the minimal functions we expect from a Handle<T>? In my opinion they should follow the future and task interface
* wait : Handle<T>
* wait_until : Handle<T>, Time
* wait_for : Handle<T>, Duration
* get : Handle<T> -> Handle<T>::result_type
* is_ready : Handle<T> -> bool 
* has_exception: Handle<T> -> bool 
* has_value: Handle<T> -> bool 

Handle must be Movable or CopyConstructible (or boths). Do we need Handles that are neither Movable nor CopyConstructible ?

Some handles will move the result when calling get() (as do unique_future) while others will do copy (as do shared_future) so Handle<T>::result_type will depend on this feature. If we follow C++0x

    unique_future<T>::result_type = T&&
    unique_future<&T>::result_type = T&
    unique_future<void>::result_type = void

    shared_future<T>::result_type = const T&
    shared_future<&T>::result_type = T&
    shared_future<void>::result_type = void

Some handles will allow to be interruped, 
* interrupt: Handle<T>
* interrupt_requested : Handle<T> -> bool

Others  handles could be detached
* detach: Handle<T>
* joinable: Handle<T> -> bool

On top of this we can add some functions that work on several functions
* async_call_all : AE, F_1, ..., F_N -> HandleTuple 
    evaluate N function asynchronously 
* wait_for_all : Tuple Handle's
    wait for the completion of all the handles
* wait_for_any : Tuple Handle's -> unsigned
    wait for the completion of any of the handle in the tuple and return its index
* get_all : Tuple Handle's -> ResultTuple 
    wait for the completion of all the handles and return its results in a tuple.

Or even 
* conc_wait_for_all : AE, F_1, ..., F_N -> ResultTuple
    evaluate N function asynchronously  and returns its results in a tuple
* conc_wait_for_any : AE, F_1, ..., F_N -> ResultVariant | Result
    evaluate N function asynchronously  and returns once the first completes with its results in a variant of the result types or Result if all the result types are the same.

Could we get a consensus on the minimal features? Any idea for better names for these Asynchronous Executor, and Asynchronous Completion Handle concepts, and the associated functions (async_call, fork, launch, spawn ...)?

Thanks,
Vicente

P.S. The InterThreads library include a probe of concept of this Asynchronous Execution framework. It is available at Boost Sandbox: https://svn.boost.org/svn/boost/sandbox/interthreads and Boost Vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=interthreads.zip&directory=Concurrent%20Programming&