|
Boost : |
From: Thore Karlsen (sid_at_[hidden])
Date: 2005-12-15 23:26:26
On Thu, 15 Dec 2005 21:20:23 -0500, Jody Hagins
<jody-boost-011304_at_[hidden]> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk