Re: [boost] [threadpool] new version - interface suggestions

Subject: Re: [boost] [threadpool] new version - interface suggestions
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-01-14 15:20:33

----- Original Message ----- 
From: <k-oli_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, November 22, 2008 8:40 PM
Subject: [boost] [threadpool] new version - supporting future library(C++0x) from Anthony Williams

> 
> Hello,
> 
> I've uploaded a new version of boost.threadpool (v17) at 
> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-threadpool.v17.tar.gz&directory=Concurrent%20Programming&.

Hi, 

I have some suggestion to the interface:

Task class
* Adding a get_future function allows to use wait_for_all and wait_for_any or overload these functions for tasks.
* A task is an asynchronous completion token so it will be great if it shares the same interface as futures:
    * Add wait, wait_until, wait_for
    * Add a callback setting
and as threads 
    * Add detach (this allows to free the interrupter)
    * Add interruption_requested
    * Add join (equivalent to wait)
    * Add joinable (equivalent interrupter pressent)

* It could be useful to get the  pool  associated to a task (this is possible if task is a inner class of pool, see below). This allows a user having a reference to a task to shutdown a thread pool
    * Add a function get_thread_pool()

* Task can also be seen as asynchronous executors which are able to fork a new task associated to the execution of a function
    * Add a fork function which will submit a new function to the pool associated to the task
        task<R>::fork(f);

    * Add a this_task::fork function which submit a new function to the pool associated to the current worker. This avoid to pass the task or pool as parameters to other functions called in this thread.

Pool class

* It will be interesting to be able to wait actively on other synchronization mechanisms. 
    * Add a public re_schedule_until_ready
    template <typename ACT>
    void re_schedule_until_ready(ACT& fut ) { 
        if ( tss_worker_.get() ) {
            while ( ! fut.is_ready() )
                if ( ! tss_worker_->re_schedule() ) break;
        }
    }
For example this_task::sleep_until and sleep_for:
    struct time_reached {
        time_reached(system_time& abs_time) : abs_time(abs_time) {}
        bool is_ready() {
            return get_system_time() >= abs_time_;
        }
    };

    this_task::sleep_until(system_type& abs_time) {
        if (this_task::get_thread_pool()) {
            time_reached t(abs_time);
            this_task::get_thread_pool()->re_schedule_until_ready(t);
        } else this_thread::sleep_until(abs_time);
    }

BTW, the friend declaration in tp::pool 'template< typename R > friend class task;' do not works for its use in its inner class 'template< typename Pool > class impl_future_wrapper' (At least not with cygwin gcc 3.4.4

Implementation
* I see that the  struct impl_future declare its functions virtual? If you declare the task class local to the pool class you will know the pool type and so no need to use a wrapper, i.e. 
What do you think?

The single inconvenient is that the user needs to declare its task as

    pool_type::task<int> tsk = p.submit(f);

But if you we register the task class with Boost.Typeof the user can write

    BOOST_AUTO(tsk, p.submit(f))

or in C++0x

    auto tsk = p.submit(f);

You just need to add a file
    // boost/tp/typeof/task.hpp
    #ifndef BOOST_TP_TYPEOF_TASK__HPP

    #include <boost/tp/task.hpp>
    #include <boost/typeof/typeof.hpp>
    #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP()
    BOOST_TYPEOF_REGISTER_TEMPLATE(boost::tp::task, 1)
    #endif

Documentation
* It is not clear from the documentation which is the role of timed_submit.  I supose it is returns if the task can not be put on the channel queue. Could you clarify?

Best regrads,
_____________________
Vicente Juan Botet Escribá