threading support in python

[Sandra-24]

Steve Holden wrote:
> Quite right too. You haven't even sacrificed a chicken yet ...

Hopefully we don't get to that point.

> You write as though the GIL was invented to get in the programmer's way,
> which is quite wrong. It's there to avoid deep problems with thread
> interaction. Languages that haven't bitten that bullet can bite you in
> quite nasty ways when you write threaded applications.

I know it was put there because it is meant to be a good thing.
However, it gets in my way. I would be perfectly happy if it were gone.
I've never written code that assumes there's a GIL. I always write my
code with all shared writable objects protected by locks. It's far more
portable, and a good habit to get into. You realize that because of the
GIL, they were discussing (and may have already implemented) Java style
synchronized dictionaries and lists for IronPython simply because
python programmers just assume they are thread safe thanks to the GIL.
I always hated that about Java. If you want to give me thread safe
collections, fine, they'll be nice for sharing between threads, but
don't make me use synchronized collections for single-threaded code.
You'll notice the newer Java collections are not synchronized, it would
seem I'm not alone in that opinion.

> Contrary to your apparent opinion, the GIL has nothing to do with
> reference-counting.

Actually it does. Without the GIL reference counting is not thread
safe. You have to synchronize all reference count accesses, increments,
and decrements because you have no way of knowing which objects get
shared across threads. I think with Python's current memory management,
the GIL is the lesser evil.

I'm mostly writing this to provide a different point of view, many
people seem to think (previously linked blog) that there is no downside
to the GIL, and that's just not true. However, I don't expect that the
GIL can be safely removed from CPython. I also think that it doesn't
matter because projects like IronPython and PyPy are very likely the
way of the future for Python anyway. Once you move away from C there
are so many more things you can do.

> I think the suggestion was rather that abandoning Python because of the
> GIL might be premature optimisation. But since you appear to be sticking
> with it, that might have been unnecessary advice.

I would never abandon Python, and I hold the development team in very
high esteem. That doesn't mean there's a few things (like the GIL, or
super) that I don't like. But overall they've done an excellent job on
the 99% of things the've got right. I guess we don't say that enough.

I might switch from CPython sometime to another implementation, but it
won't be because of the GIL. I'm very fond of the .net framework as a
library, and I'd also rather write performance critical code in C# than
C (who wouldn't?) I'm also watching PyPy with interest.

-Sandra