[Python-Dev] Free threading

[Paul Prescod]

Tim Peters wrote:
> 
>...
> 
> You can't get massive scalability using OS threads, unless the OS is an
> oddball specifically designed for that.  Worming around the bloat of Windows
> and Linux (etc) OS threads is Stackless Python's natural domain (simulated
> threads).  The catch, of course, is they that don't run in parallel!  Or
> maybe by "massive" you mean a few dozen?  I worked in the "massively
> parallel supercomputer" biz, so I'm thinking more on the order of a few
> thousands of dozens.  I bet you're not.

I am thinking about getting as many threads as there are processors to
run truly in parallel.

> > ...
> > Why do people use mod_python, fcgi, mod_snake, mod_php and all of those
> > other things instead of pure CGI?
> 
> Beats me why people bother with web programming at all <wink>.

Yeah, that describes alot of us in the Python world. I think that
explains the emergence of PHP. <0.1 wink> Even Zope is really an OO
database that made a few concessions to the fashionable object delivery
mechanisms of the day. 

>...
> IIRC, Greg's fabled free-threading version of Python took a speed hit of
> about a factor of 2 (for a program using only 1 thread, compared to that
> same program without the free-threading patches).

The Perl guys considered this unacceptable and I can kind of see their
point. You have two processors but you get roughly the same performance
as one?

>..
> Well, the idea that threads don't share information is foreign to every
> intense belief about the world *I've* ever been paid to adopt <wink>, and
> I'm not enough of a Windows geek to believe "threads are always the answer"
> even so.  A pool of worker processes using OS-specific IPC as needed works
> great in my real-life experience, and if information sharing is rare, works
> especially great because it's not *fighting* the OS and C libraries tooth
> and nail.

I really don't see this as fighting anything. There are thousands of
C-coded libraries out there that can be used in multiple C threads
without sharing information between them. Some of those libraries happen
to be interpreters (e.g. PHP, VBScript) that are much more popular in
embedded server applications than Python. Maybe just a coincidence but I
think that there are a host of reasons and this may be one of them.

> What of your hypothetical user earlier, who "isn't going to be happy with
> the price of ... using IPC for information sharing either"?  That is, in
> what sense do isolated threads leave her happy about her information sharing
> needs?  

You share information (if at all) through the threaded host. The host
handles serialization of access to shared information. E.g. Apache wants
to tell you about the cookies that go with a request. That shouldn't be
copied from one process to another. It should be "just available."
Sendmail wants to tell you about the message contents of the message you
are filtering. Your SQL database with Python stored procedures has huge
shared state but the Python procedures would never share state
themselves. Your video game has a set of objects available representing
physical objects. Python interpreters would never talk to each other
about them directly -- they would always move the objects around the
objectspace and the engine routes the information between the
interpreters. 

There is no "IPC" between Python programs. All communication is between
the host environment and the interpreter. If the host chooses to share
the information with other interpreters then it is the host's job to
manage serialization and it is the host's fault if performance lags.

Anyhow, these servers exist and use threads for parallel processing.
Either we play nicely with them as a good citizen or you don't. We bend
over backwards to be a good embedded citizen on many other issues. We
could argue that Apache 2 made a wrong turn in moving from processes
towards threads but I think that's a little like announcing the falling
of the tree in the wood.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook