Michael Becke wrote:
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:
- 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
Yeah, I was hoping for an async solution as well. Imagining a huge site with lots of pipelining request you could easily waste a lot of resources when using threads.
Odi
-- _________________________________________________________________ NOSE applied intelligence ag
ortwin gl�ck [www] http://www.nose.ch software engineer hardturmstrasse 171 [pgp id] 0x81CF3416 8005 z�rich [office] +41-1-277 57 35 switzerland [fax] +41-1-277 57 12
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
