[1] http://danlincan.3owl.com/gsoc/Proposal.pdf
I have some questions:
* Why the submit function of all the thread pools doesn't returns the
same?
* What is the advantage of returning future from submit call?
....
My personal big issue with a Boost.Thread threadpool is why adding one is
necessary when forty lines of C++11 code using Boost.ASIO implements you
one:
/*! \class thread_pool
\brief A very simple thread pool based on Boost.ASIO and std::thread
*/
class thread_pool {
class worker
{
thread_pool *pool;
public:
explicit worker(thread_pool *p) : pool(p) { }
void operator()()
{
pool->service.run();
}
};
friend class worker;
std::vector< std::unique_ptr<thread> > workers;
boost::asio::io_service service;
boost::asio::io_service::work working;
public:
//! Constructs a thread pool of \em no workers
explicit thread_pool(size_t no) : working(service)
{
workers.reserve(no);
for(size_t n=0; njoin();
}
//! Returns the underlying io_service
boost::asio::io_service &io_service() { return service; }
//! Sends some callable entity to the thread pool for execution
template<class F> future::type>
enqueue(F f)
{
typedef typename std::result_of::type R;
// Somewhat annoyingly, io_service.post() needs its
parameter to be copy constructible,
// and packaged_task is only move constructible, so ...
auto
task=std::make_shared(std::move(f)); // NOTE to
self later: this ought to go to std::packaged_task
service.post(std::bind([](std::shared_ptr t) {
(*t)(); }, task));
return task->get_future();
}
};
... and you're done. Moreover, this thread pool integrates seamlessly with
Boost.ASIO ioservice callback dispatch which is a huge plus. I took that
example from some page on the internet, so I don't claim I wrote most of the
above.
Do bear in mind before you respond that parts of Boost.ASIO are scheduled to
enter the standard in TR2, therefore no you won't need Boost.ASIO as a
dependency soon.
I'm not ruling out the merit of a Boost.Thread threadpool. For me personally
though, the hurdle is very significantly raised: you need to strongly prove
to me why your proposed thread pool is much superior to a Boost.ASIO based
threadpool. Otherwise I will zero score the GSoC proposal, because in the
end we need other proposed projects more.
By the way, I actually don't object at all if your proposed Boost.Thread
threadpool is a thin wrapper of Boost.ASIO. That, actually, is just fine
with me, though I'd doubt Google would feel it substantial enough for GSoC
funding seeing as it would be finished within a week.
Niall
