Boost logo

Boost :

From: Thore Karlsen (sid_at_[hidden])
Date: 2005-12-15 15:31:14

On Thu, 15 Dec 2005 14:57:18 -0500, "Arkadiy Vertleyb"
<vertleyb_at_[hidden]> wrote:

>> Thus limiting your #simultaneous connections to the number of threads in
>> your thread pool. You can do better by doing all the parsing, request
>> splitting, etc. in a async-using main acceptor thread and handing off
>> smaller bits of work to the threads in the pool. That way you can
>> exploit the fact that some threads may finish some parts of a given
>> request early, and may be available to serve other connections.

>Thus serving the same connection from different threads? I just don't
>happen to like how this would impact the processing algorithm...

You can do what I do, which is to always service the same connection
from the same thread. Since my clients can pipeline requests, I don't
want requests to be handled out of order. Assigning a connection to a
thread in the thread pool is an easy way to solve that problem.

Packets are read and parsed in the communications thread, and I send out
smaller units of work to the thread pool. From the handlers that are
executed in the thread pool I can queue up reply packets to be sent by
the communications thread.

This way I can connect thousands of clients and keep them connected all
day, and service them all simultaneously from a very small number of
threads. I could even do everything in one thread if I wanted to.

I've done thread-per-connection servers as well, and to be honest I
think an async design is easier to work with. If you have a good
framework like asio, it can actually end up being cleaner. (At least to
my eyes.)

Be seeing you.

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