Re: [boost] asio formal review begins

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.