[Python-Dev] Another 1.6 wish

[Greg Stein]

On Fri, 19 Nov 1999, Christopher Petrilli wrote:
> Andrew M. Kuchling [akuchlin@mems-exchange.org] wrote:
> > Barry A. Warsaw writes:
> > >We had some discussion a while back about enabling thread support by
> > >default, if the underlying OS supports it obviously.  I'd like to see

Definitely.

I think you still want a --disable-threads option, but the default really
ought to include them.

> Yes pretty please!  One of the biggest problems we have in the Zope world
> is that for some unknown reason, most of hte Linux RPMs don't have threading
> on in them, so people end up having to compile it anyway... while this
> is a silly thing, it does create problems, and means that we deal with
> a lot of "dumb" problems.

Yah. It's a pain. My RedHat 6.1 box has 1.5.2 with threads. I haven't
actually had to build my own Python(!). Man... imagine that. After almost
five years of using Linux/Python, I can actually rely on the OS getting it
right! :-)

> > That reminds me... what about the free threading patches?  Perhaps
> > they should be added to the list of issues to consider for 1.6.
> 
> My recolection was that unfortunately MOST of the time, they actually
> slowed down things because of the number of locks involved...  Guido
> can no doubt shed more light onto this, but... there was a reason.

Yes, there were problems in the first round with locks and lock
contention. The main issue is that a list must always use a lock to keep
itself consistent. Always. There is no way for an application to say "hey,
list object! I've got a higher-level construct here that guarantees there
will be no cross-thread use of this list. Ignore the locking." Another
issue that can't be avoided is using atomic increment/decrement for the
object refcounts.

Guido has already asked me about free threading patches for 1.6. I don't
know if his intent was to include them, or simply to have them available
for those who need them.

Certainly, this time around they will be simpler since Guido folded in
some of the support stuff (e.g. PyThreadState and per-thread exceptions).
There are some other supporting changes that could definitely go into the
core interpreter. The slow part comes when you start to add integrity
locks to list, dict, etc. That is when the question on whether to include
free threading comes up.

Design-wise, there is a change or two that I would probably make.

Note that shoving free-threading into the standard interpreter would get
more eyeballs at the thing, and that people may have great ideas for
reducing the overheads.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/