Subject: Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-29 14:23:42
Le 29/04/13 17:40, Niall Douglas a écrit :
>>> 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.
>> 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
> 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.
I was not aware that there was a AFSIO GSoC project as described here
https://svn.boost.org/trac/boost/wiki/SoC2013#Boost.ASIO and that this
project propose also thread pool. I understand better now your concerns.
I have no problem at all if there is only student that works on a thread
pool proposal, but I think the approaches are quite different and so it
will be worth to have students fr both projects.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk