Python threading?

[brueckd at tbye.com]

On Thu, 26 Sep 2002, Thomas Weholt wrote:

> This might be just a stupid question, but I'm trying to implement a
> filesharing-app, based on the BaseHTTPServer in the standard python-distro.
> This will of course be heavy IO-processing involved. Will threading still be
> a bad idea? The project is aimed at small user-groups ( I do not think one
> person will have more than say 5-10 concurrent connections at a time, most
> of them downloading files 1MB + in size),

At those low load levels, threads will be fine.

> as if threading is a very bad idea no matter what, still it's used almost
> everywhere ( I got no statistics to back up that statement ;-) ).

You have to factor in the issue of complexity too though. The threading
approach is almost always much simpler and many applications don't need to
be high performance, so threading is acceptable. That said, the asynch
approach _is_ useful to know and understand - if for no other reason than
it makes you understand the problem from a very different angle. And after
awhile it really starts to "click" in your head and make sense. State 
machines are nifty. :)

> NB! It would be nice to be able to limit the number of threads, actually the
> number of concurrent connections, on the server too, so if anybody has any
> comments on some way of doing that and still handle request gracefully

Is the client side a web browser or a custom app? Your request handler 
could return a nice "server is busy" (e.g. HTTP 503) message to a browser, 
but if you want to explicitly cap the number of threads you'll need to 
subclass the server. It's been awhile since I've looked at SocketServer, 
but I think it has a check_request or verify_request or something method 
that you could override to send back an HTTP 503 if the server is 
overloaded (already has N threads running) and then return false (as in, 
"don't process this request any further).

-Dave