On Tue, Nov 16, 2010 at 1:04 AM, Bruno Santos <bsantos@av.it.pt> wrote:
The thread pool is a BAD IDEA.
Interesting. I've found a group of users that want to have a separate pool of threads for performing heavy lifting tasks from the server side, who have requested explicitly to have a dedicated thread pool for application-specific (potentially long-running synchronous IO bound) tasks so it doesn't hold up the I/O threads that are bound to a single io_service instance. The idea is to have a separate thread pool (with a configurable number of threads) that simply allows for doing application-specific computation. This makes sense on the server side, but the client side I don't see much of a benefit of it -- except for potentially holding up the I/O and handlers queued up for other connections being serviced by the io_service. This made sense especially for things like streaming music over HTTP, where the client will not want the DSP code to hold up the I/O of a potentially large amount of data coming down the wire. Another use case for this would be for a crawler to be able to offload the parsing/processing of content from multiple connections to a pool of threads dedicated to just doing the work, and not holding up all the queued handlers associated with an io_service. That said, the interface can be made to not require a thread pool to be supplied in the constructor of the client, and in which case it will just use the io_service that it owns.
I'm very interested in your library, I would like to use it with other async services I have implemented using Boost Asio. For this a need to specify which io_service your library is going to use and no threads whatsoever.
The way it is done right now, if you look at the examples, is that the HTTP server and HTTP client objects own their own io_service instances. It can be modified to take in an io_service as a parameter by reference, and if that constructor is used it will use that provided io_service instead of creating its own. I suppose this can be done with a pointer to a boost::asio::io_service and a flag that says whether the io_service is owned or provided by reference. It is doable and I'd add that to the things to add for me to support before I release on Friday version 0.8, thanks for the suggestion. :)
I like the idea of boost Asio, having a single io_service where I can put as many threads to run as I would like (this would usually be a number of threads equal to the number of cores).
I've found though that in some cases especially where your service actually does something significant other than constructing a string and then piping that string out (think graph algorithms, SQL queries, map/reduce, etc.) then having an application-specific thread pool actually helps with scalability (not necessarily the performance) of the service to handle more connections and get the data out smoothly through a separate set of threads doing the I/O (or at least running the lightweight I/O event handler functions). The simple use case for the HTTP server already allows you to run the server instance on multiple threads, which really just wraps the Boost.Asio io_stream::run() that gets spread out into however many threads you want. If you look at http://cpp-netlib.github.com/0.8-beta/hello_world_server.html and the note at the bottom, it's basically the same as io_service::run() being invoked on multiple threads. Thanks for the feedback and I hope this helps too. :) -- Dean Michael Berris deanberris.com