Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project

Subject: Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
From: Niall Douglas (ndouglas_at_[hidden])
Date: 2013-04-29 11:40:10

> > 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.
> This is your right,  but I don't know how the fact you can write easily
the thread
> pool you need to diminish a generic thread pool working well with futures.
> [snip]
> Hopping this helps you to understand the project I'm looking for.

There are many ways systemically of implementing futures. The way you and
Anthony have taken to date is a non-intrusive approach such that futures
stand alone. This is great for not forcing design onto third parties and is
a decentralised POSIX-y approach, but it comes with significant performance
and memory costs because it's hard to get standalone, non-intrusive futures
to batch themselves without sacrificing performance.

An alternative approach is to assume a central dispatcher/event loop which
can optimize then() chaining because it knows of all futures and their
relationships currently in flight (this is a much more centralized statist
NT-y approach, and it you can see that philosophy clearly in Microsoft's
N3428). You can see an example of this approach to implementing future
chaining with multiple dependencies which extends Boost.ASIO in
https://github.com/ned14/TripleGit/blob/master/triplegit/include/async_file_
io.hpp#L785. I also went ahead and implemented N3428's when_all() which
returns a future chained to multiple input futures, not that I claim the
implementation mature yet.

My concern with Boost.ThreadPool right now is that it could get in the way
of the latter approach. I have zero objection to a formulation which
embraces both approaches, but when you ask why a thread pool isn't in the
standard, I think it's because until we've fixed futures implementation and
all the composibility and chaining we're sure we need, and made sure that
interops smoothly with the forthcoming TR2 networking proposal, then and
only then is it wise to proceed with threadpool design.

All that said, this is purely a cautious opinion of mine. You're one of the
Boost.Thread maintainers, so I happily defer to your judgment on this. If
you think we need a threadpool now, you'll find no opposition from me.

Niall

---
Opinions expressed here are my own and do not necessarily represent those of
BlackBerry Inc.