On Thu, 15 Dec 2005 21:20:23 -0500, Jody Hagins <jody-boost-011304@atdesk.com> wrote:
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... the thread only owns the connection for the life of one work unit (well, technically, if it were reading, it would read as much as possible, package the information, then process as much as possible). It would then release the "object" and become available for another piece of work. That piece of work may come from the same connection or another, it does not really matter.
Of course it matters. The client could sit idle for an hour before it sent the next request, and the server thread would be stuck in a blocking read waiting for data from the client, unable to service other clients.
So, in this instance, I fail to see how it does not scale. It scales remarkably well, actually. I can handle 1000 connections with a thread pool of any size, even 1 (though that would defeat the purpose since all the work would pile up waiting for that one thread).
So if you can do this with blocking, synchronous I/O, why do you think asio exists? Why do you think people are arguing for asynchronous I/O in favor of synchronous I/O? -- Be seeing you.