Simple threaded web-server based on BaseHTTPServer?
mhammond at skippinet.com.au
Thu Jan 31 14:04:35 CET 2002
Paul Rubin wrote:
> Mark Hammond <mhammond at skippinet.com.au> 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
> 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