Hi, I have just released the version 0.4, which includes since my last publicly announced version 0.3.0: Version 0.4.0, Fevrary 8, 2009 Improvements + bug fixes New Features: * New free functions for all the AsynchronousCompletionToken operations, providing a higher degree of freedom. * Missing have_all_values(), have_all_exception() and are_all_ready() functions on AsynchronousCompletionToken fusion tuples. * get_all: getting all the values from a tuple of AsynchronousCompletionToken works now. * fork_after overloaded for a single dependency * wait_all overloaded for a single ACT. * wait_for_all evaluate one of its elements on the current thread * No need to use wait_and_get() on thread_specific_shared_ptr<> to synchronize with the decoration if the thread is created using a AsynchronousExecutor decorator. In this case the synchro is done before returning the AsynchronousCompletionToken. See the tutorial and the mono_thread_id example. Fixed Bugs: v0.2#1: ae::get_all do not work yet. get_all() do not work because fusion transform sequence function can not take non const sequences. I have emulated it using set_all() and a transformation for a tuple of _ACT to a tuple of result_type. v0.3.1#1: keep alive mechanism crash when setting set_on_dead_thread() before enabling the mechanism. This was due to the fact that there were no default data for the backup. v0.3.1#2: keep alive mechanism do not detect dead threads. We need to reset the counters only when the period is 0. v0.3.1#3: The set_on_dead_thread() setting is not recovered by embeeding kep_alive enablers/disablers. The problem is that the on_dead() the function and the thread pointer were stored on the backup. It is enough to store them on the thread_keep_alive_ctx and make the functions thread_safe. Version 0.3.1, January 25, 2009 bug fixes Fixed Bugs: v0.3#3: scheduler::do_test_fork_after_wait do not work yet. To solve this issue it enough to define boost::move for tp::task v0.3#2: scheduler::do_test_fork_after_get do not work yet. To solve this issue it enough to define boost::move for tp::task v0.3#1: scheduler::do_test_wait_for_any do not work yet. Not reproductible v0.2#2: Some trouble with the use of tp::pool directly, use scheduler instead. Four issues. The parameter to fork on tp:pool was a const F& instead of a F. Direct use of fork_all resolved for the other AsynchronousExecutor by ADL, which could not be the case for the tp::pool. fork specialization for tp::pool incorrect. use of the default handle instead of asynchronous_completion_token traits class For those who don't know the library yet here are some of its features: * An asynchronous execution framework working with AsynchronousExecutor and AsynchronousCompletionToken. It includes some generic functions working on AsynchronousExecutor and AsynchronousCompletionToken concepts: * fork and fork_all to execute functions asynchronously. * fork_after: request an AsynchronousExecutor to execute a function asynchronously once each one of AsynchronousCompletionToken in the dependency tuple parameter are ready. It is similar to the async_with_dependencies proposed Peter Dimov. * generic wait_for_all, wait_for_any to execute asynchronously functions and wait for the completion of all or any of them. * generic get, join, ... free functions to synchroyze on an AsynchronousCompletionToken * generic get_all, join_all, ... free functions to synchroyze on multiple AsynchronousCompletionTokens * Some AsynchronousExecutors and AsynchronousCompletionTokens models * basic_threader: can be seen as a thread factory executing asynchronously a function on the returned thread. * launchers: Lanchers can be seen as a future factory executing asynchronously a function on a hiden thread. * threader/joiner: A Threader runs a unary function in its own thread. A Threader can be seen as a Joiner factory executing asynchronously a function on a thread encapsulated on the returned Joiner. The joiner is used to synchronise with and pick up the result from a function or to manage the encapsulated thread. * tp::pool and tp::task customization as an AsynchronousExecutor and an AsynchronousCompletionToken respectively. tp::pool can be seen as a tp::task factory executing asynchronously a function on a pool of threads. a generic asynchronous_executor_decorator which allows to decorate the function to be evaluated asynchronously. * Some thread extension * A thread_decoration class allowing to define setup/cleanup functions which will be called only once by thread (if the thread function is decorated with thread_decorator): setup before the thread function and cleanup at thread exit. It is used together with asynchronous_executor_decorator * A thread_decorator/thread_decorate class/function which decorate a thread function in order to call the setup and the cleanup of all the thread_decorations. * A thread specific shared pointer which is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one. * A thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program. The library 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& Includes every thing on the Sandbox + Html documentation + Boost.Futures + Boost.ThreadPool adaptations I'd appreciate it if people could take a look, test it on their compiler and give me some feedback. Best regrads, Vicente Juan Botet Escribá