On Fri, Nov 21, 2008 at 10:25 PM, Oliver Kowalke <k-oli@gmx.de> wrote:
Hi Dean,
// 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(); }
sorry, but i don't see the benefit
Maybe some additional functions are required which create customized pool accessible over launch_in_pool. Singleton from Andrei Alexandrescu comes into my mind (tracks the order of creation/destruction of singletons) - a implementaion was announced some months ago in the mailing list.
The version you quoted allowed you to create your own thread pool and pass that in as the second parameter to the launch_in_pool(...) function. That means, any type that models the ThreadPool concept should qualify as a thread pool. If you want a special type of thread pool with a different configuration from the default (as presented in version 2) that's controllable using compile-time definitions (for strategies used, etc.) then you'll just have to write your own thread pool implementation and make sure you write a concept_map to adapt your implementation to the ThreadPool concept. Of course this assumes three things: 1. The ThreadPool concept is defined. 2. The local static initialization and destruction sequence is standardized across vendors as what the C++0x standard proposes. 3. The implementation of the standard thread pool is defined by the standard and not vendor-specific. In case 3, then vendors may be able to give more options about how the default thread pool can be configured at compile time. If all else fails, version 1 (which you have quoted) will be the implementation that you can use -- write your own or use an existing thread pool adapted to the ThreadPool concept. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.