Simple thread pools

Josiah Carlson jcarlson at uci.edu
Fri Nov 12 02:23:53 EST 2004


Mike Meyer <mwm at mired.org> wrote:
> 
> Josiah Carlson <jcarlson at uci.edu> writes:
> 
> > Steve Holden <steve at holdenweb.com> wrote:
> > All I'm saying is that you can get the same kinds of concurrency, same
> > kinds of throughput, same kinds of elapsed times, etc., with an
> > asynchronous approach and a single thread.  I suppose 'whatever floats 
> > [our] boats' and 'whatever implementation presents itself in the most
> > timely manner'.
> 
> Except that multi-threaded code is prone to obscure, hard-to-isolate
> bugs. Having done both multi-threaded and async servers, I'll take the
> async version every time.

Any time I have the time to do async (99.99% of the time), I do. 
On the rare occasion I'm just lazy, and go with a pre-made module that
only supports threads/forking (like BaseHTTPServer when I wanted a web
interface to a daemon, and I didn't want to implement HTTP).


I had offered (in python-dev) to translate the various server classes
that are available into an two-part system, one that handles the getting
the data to the handlers (thread, forked, async) and the actual generic
non-blocking handlers (anything that blocks required calling a deferring
mechanism that is thread/async dependant, apparently similar to
Twisted's deferred system).  In doing the translation, Python would get
a nice generic server framework (threaded, forked, async), but since
we/they are looking to get a subset of Twisted in anyways, creating a
new version is basically a waste.


 - Josiah




More information about the Python-list mailing list