Critical sections and mutexes

brueckd at tbye.com brueckd at tbye.com
Wed Oct 24 22:29:51 EDT 2001


On Wed, 24 Oct 2001, Chris Tavares wrote:

> Isn't this relying rather heavily on the implementation of a specific
> version of the python interpreter, though?

I'd rephrase that as relying on the well-documented behavior of many
versions over several years of the same implementation. This isn't exactly
some odd quirk in a dark corner of the interpreter...

> Removing the global interpreter lock (and these semantics that you're
> leaning on)  has been the focus of some serious effort in the past.

Yes... and after that effort the GIL is still there. If it helps you sleep
better, always do your own locking and assume the GIL doesn't exist. :)
I'm just saying that a lot of times you're solving problems you don't
have, that's all.

> Does jython share this same behavior?

Don't know, don't care.

> What about the version with the "free threading patches" from a couple
> of years ago?

What about it? Instead of building my app based on the behavior of the
standard Python interpreter, I should make sure it works on some patched
version? Naah...

> You're asking for trouble in the long run if you rely on this, I think.

You're overestimating the cost of changing a Python program, I think.

Should the GIL be removed someday down the road, *all* multithreaded apps
would become suspect and overdue for a thorough review.

FWIW, I don't think the GIL will ever go away, or if it does, we'll end up
with something that gives the same behavior. Think about it: no GIL means
that a normal Python program (ie no extension modules in use) could crash
the interpreter. Maybe it's just me, but Guido et al have gone to great
lengths to make it nearly impossible to do that (and when it happens, it's
considered a bug and is fixed ASAP). The GIL is what lets multi-threaded
Python programs still behave like Python programs should.

-Dave





More information about the Python-list mailing list