Boost logo

Boost :

Subject: Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
From: Niall Douglas (ndouglas_at_[hidden])
Date: 2013-04-25 15:42:55

> > [1]
> >
> I have some questions:
> * Why the submit function of all the thread pools doesn't returns the
> * 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

/*! \class thread_pool
\brief A very simple thread pool based on Boost.ASIO and std::thread
class thread_pool {
        class worker
                thread_pool *pool;
                explicit worker(thread_pool *p) : pool(p) { }
                void operator()()
        friend class worker;

        std::vector< std::unique_ptr<thread> > workers;
        boost::asio::io_service service;
        boost::asio::io_service::work working;
        //! Constructs a thread pool of \em no workers
    explicit thread_pool(size_t no) : working(service)
                for(size_t n=0; n<no; n++)
                for(auto &i : workers)
        //! 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<typename std::result_of<F()>::type>
enqueue(F f)
                typedef typename std::result_of<F()>::type R;
                // Somewhat annoyingly, needs its
parameter to be copy constructible,
                // and packaged_task is only move constructible, so ...
task=std::make_shared<boost::packaged_task<R>>(std::move(f)); // NOTE to
self later: this ought to go to std::packaged_task<R()>[](std::shared_ptr<boost::packaged_task<R>> 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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at