Hi Michael, > > No, they use thread pools. Once an incoming connection is accepted, > > a service thread is allocated for handling all requests coming in > > through that connection, sequentially. > > Using this model is would seem that a thread is tied up for the life of > a keep alive connection. Is this handled the same way when async > support is available? I was envisioning something more like the > following: > [...see below...]
You're right. It's better to have a pool for both server connections and service threads. I guess I've been programming too much on the service thread level lately. The service threads don't need a pool for server connections, but the thread(s) handling the server socket(s) do. Thanks to you and Odi for adjusting my perspective :-) cheers, Roland > - A thread listens for connect operations on a server socket and adds > the opened sockets (connections) to a queue of pending async reads. > - Requests are dispatched from the queue of connections to waiting > threads, which process a single request. > - Once the request is processed the connection is either closed or > re-queued for further processing. > - The queue/pool of connections is then responsible for closing > connections that either go stale or that haven't been serviced within a > certain period of time. > > Again this is a little off topic, but I'm trying compare/contrast the > use case for the client and server side in regard to connection use. > > Thanks, > > Mike > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
