[Python-Dev] Pythonic concurrency

Bill Janssen janssen at parc.com
Mon Oct 10 21:26:45 CEST 2005


> With the Mojam middleware stuff I suffered quite awhile with a
> single-threaded implementation that would hang the entire webserver if a
> backend query took too long.  I realized I needed to do something (threads,
> asyncore, whatever), but didn't think I understood the issues well enough to
> do it right.

Yes, there's a troublesome meme in the world: "threads are hard".
They aren't, really.  You just have to know what you're doing.  But
that meme seems to keep quite capable people from doing things they
are well qualified to do.

> Once I finally bit the bullet and switched to a multithreaded
> implementation, I didn't have too much trouble.


> Of course, the application
> was pretty mature at that point and I understood what objects were shared
> and needed to be locked.

Kind of like managing people, isn't it :-?.

I've done a lot of middleware myself, of course.  ILU was based on a
thread-safe C library and worked with Python threads quite well.
Lately I've been building UpLib (a threaded Python service) on top of
Medusa, which has worked quite well.  UpLib handles calls
sequentially, but uses threads internally to manage underlying data
transformations.  Medusa almost but not quite supports per-request
threads; I'm wondering if I should just fix that and post a patch.

Or would that just be re-creating ZServer, which I admit I haven't
figured out how to look at?


More information about the Python-Dev mailing list