[boost] [interthreads] Library under development v0.4

Subject: [boost] [interthreads] Library under development v0.4
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-08 20:01:05

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á