From: Thore Karlsen (sid_at_[hidden])
Date: 2005-12-15 17:01:20
On Thu, 15 Dec 2005 16:29:51 -0500, Jody Hagins
>> And how do you presume that Arkadiy is doing that when he's doing all
>> synchronous communication in the worker threads? How can one of his
>> threads service another connection when it's blocked waiting for data
>> from the client, or blocked sending data to a client?
>> If he is truly servicing multiple connections from a single thread
>> using blocking I/O I'd love to know how he's doing it.
>This thread of discussion has gone way past its intent, and I'm not sure
>this is the place for discussions on thread pool implementations.
>However, just to give you something to think about... Why does the main
>thread have to do any I/O at all? One could easily conceive a thread
>that looks for work to be done, then sends that work to an available
>thread for processing, without ever performing any I/O.
That is basically what is being done in this specific case.
There's one thread that just accepts connections, and then there's a set
of worker threads that do all the communications and processing.
My point is that once a thread is given a connection to work with, it
can't do anything else while that connection is alive. Since all
communication is synchronous, the thread will either be processing a
request, or it will be blocked trying to read or write. It can only
handle one connection at a time, and it has to handle that connection
for the lifetime of the connection.
This obviously doesn't scale. If you want to handle 1000 connections
simultaneously, you need 1000 threads.
Note that I'm not disagreeing with you in how thread pools should be
used in general, I'm only addressing this specific scenario.
But again, this is getting off topic.
-- 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