----- Original Message ----- From: "Dean Michael Berris" <mikhailberis@gmail.com> To: <boost@lists.boost.org> 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&