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