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

Subject: Re: [boost] [threadpool] new version - interface suggestions
From: k-oli_at_[hidden]
Date: 2009-01-16 08:37:08

Hello,
> Task class
> * Adding a get_future function allows to use wait_for_all and wait_for_any
> or overload these functions for tasks. 

I would prefer to keep future as an implementation detail

> * 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)

that's possible - I could rename the functions

> * 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()

I was also thinking about such constructs

> * 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);

it doubles the functionalisty of pool::submit and I want to keep the interface 
small
a task should be associated only with one function passes/submitted to the 
pool

>     * 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.

I'll think about this

> 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);
>     }

looks interresting

> 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

OK - I'll incorporate this

> 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?

Yes - you are right I should make it more clear in the documentation