From: Thore Karlsen (sid_at_[hidden])
Date: 2005-12-15 15:31:14
On Thu, 15 Dec 2005 14:57:18 -0500, "Arkadiy Vertleyb"
>> 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
-- Be seeing you.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk