Simple threaded web-server based on BaseHTTPServer?

Mark Hammond mhammond at
Thu Jan 31 14:04:35 CET 2002

Paul Rubin wrote:
> Mark Hammond <mhammond at> writes:
>>You almost certainly don't want that for the real world.  Having a
>>thread per connection will not scale well at all.
> I keep hearing this and don't doubt that it's true, but what's the
> problem really? 

Not many OS's like hundred or thousands of threads.  The overhead of 
switching this many threads becomes significant.

> If using threads in the totally obvious way is too
> slow, is the answer to re-architect the server with asyncore, or is it
> to fix the thread implementation?  

asyncore in my opinion.  Windows NT has a "completion port" concept, 
which helps a thread pool switch on a list of overlapped IO operations, 
and it is specically for high-perf, scalable servers (and uses a very 
similar model to asyncore - except the latter has no thread-pool support 
I am aware of.  OTOH, thread-pool support should consist of not much 
more than a semaphore, so knock yourself out :))

The model of such applications is actually quite elegant.  Just a large 
finite state machine.  It is often a significant architectural change 
though - all blocking operations must be identified, and associated with 
a "state".

> What happens if you use Stackless?

If Stackless has microthreads that have very little overhead (which 
implies not based on OS threads) then that would probably be a good option.


More information about the Python-list mailing list