Paul Rubin wrote: > [EMAIL PROTECTED] writes: > >>What it does do, is handle each request (from the same client too) in a >>new separate thread. Convenient if your processing intensive handle may >>otherwise slow down the main server process becoming less responsive to >>other requests. >>What it doesn't do (and what Sidd seems to search as is suggested by >>his 'select()' remark) is handle each client in a separate thread. > > > I don't know what you mean by that. It launches a new thread for each > client connection. The connection is two-way and can last as long as > desired. If you're imagining something like a web server handling > http requests, using http 1.1 keepalive, you could handle any number > of requests in that connection. > I suspect he was trying to say that BaseHTTPServer has no mechanism for handling state. As you know, of course, this is most relevant across multiple successive connections to a server from the same client, and has little to do with threads.
> >>If you want to apply SocketServer such that each client corresponds to >>one thread that handles its' requests (and maintains its state), don't >>use ThreadingMixIn - only the thread-selection will be executed in a >>separate thread. > > > What do you mean by "each client"? If a client connects, does some > stuff, disconnects, and later reconnects, how do you know that it's > the same client that's come back? The assertion that ThreadingMixIn doesn't handle *sessions* might be more appropriate, but then there's no reason why it really should (since if they were handled at all they would be better handled in the base server classes). By "each client" I suspect the OP really meant "each session", and was ignoring the fact that the same client can have multiple sessions to the same server. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
