Re: [boost] [netlib] 0.8-beta now available!

Subject: Re: [boost] [netlib] 0.8-beta now available!
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-11-15 12:55:40

On Tue, Nov 16, 2010 at 1:04 AM, Bruno Santos <bsantos_at_[hidden]> 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