LWN: Comments on "CPython without a global interpreter lock"

CPython without a global interpreter lock

mathstuf — Fri, 18 Aug 2023 13:33:49 +0000

An extension not mentioning the GIL may assume that the GIL is always locked. If it mentions the GIL, it is (usually) to drop it while calling into non-Python code (so that other Python code can make progress while, say, multiplying your 100000x100000 matrices). I think I'd actually expect a shared module mentioning the GIL to be more OK with it being a no-op. But all kinds of code could be using GIL-based assumptions of "these will never run concurrently" when manipulating shared state, so a "looks for the GIL" signal doesn't sound like a very strong signal to me.

CPython without a global interpreter lock

SLi — Fri, 18 Aug 2023 08:14:08 +0000

I know I should look at the Python source code before asking this, but since extensions are shared objects, could "not using GIL" be in some cases be detected from that .so not referencing a certain symbol?

Or is there some other care that GIL-free supporting extensions need to take besides not explicitly using the GIL?

CPython without a global interpreter lock

tialaramex — Wed, 16 Aug 2023 16:57:50 +0000

I would not characterise Python's approach as "careful", on the whole. "Slapdash" is the word which comes to mind. There are some good ideas in their compatibility approach, but they're inconsistently applied, and so I wouldn't rely on them.

My guess is that if it became normal to write environment variable checks and block execution, the response from CPython would be to change the name of the environment variable. This is an intentional foot gun, not that they'd accept that description, de-fanging it would be contrary to their purpose in offering it.

CPython without a global interpreter lock

NYKevin — Tue, 15 Aug 2023 05:41:24 +0000

If Jim's code is maintained, he can just add a startup check for the offending environment variable, and cleanly fail the import at that time with an explanatory message. If Jim refuses to do that, then it's his fault. Checking one environment variable is much cheaper than importing an entire module, so you just do it at import time and it's effectively free.

If Jim's code is unmaintained, then it's... well, not necessarily Andy's *fault*, but it is Andy's *problem* because it's his project. Such is an occupational hazard of relying on unmaintained code, in any language, but especially in Python. Python has had a very well-established practice of slowly, carefully deprecating and removing old APIs, both before and after the 2-to-3 transition. 2-to-3 was not an anomaly because it broke backcompat, it was an anomaly because it did it abruptly in a single release, and on a much larger scale than has otherwise been typical. This problem sounds much more like a classic Python deprecation than a "break the world" flag day.

CPython without a global interpreter lock

tialaramex — Sun, 13 Aug 2023 11:01:56 +0000

This sentiment makes lots of sense for Bob's home grown Python program, sole maintainer Bob, sole user Bob, chief executive and bottle washer also Bob. If it breaks it's Bob's fault. Duh.

But this sort of work is happening because people are trying to write Python at scale and having problems. Jim writes tricky code that's fine assuming the GIL, Sarah uses Jim's code in a sub-routine for her team's new project. Mark uses that sub-routine with Sarah's permission from the new Project Foo, and the Project Foo lead Andy sets the environment variable because it's a "known workaround" for a problem they have, but now about one run in twenty has corrupt results and nobody knows why.

Whose fault is the corruption? Jim? Sarah? Mark? Andy? It is likely that there's no intersection between the people who would have known this won't work and the people who did it anyway.

Maybe it's fine, but I wouldn't want to be the Python community finding that out the hard way.

CPython without a global interpreter lock

Cyberax — Fri, 11 Aug 2023 22:14:01 +0000

Good antiviruses don't lock the file, and anyway, you can still do: "do_something("blah"); time.sleep(10); os.unlink("blah");" with the same effect.

I had quite a few tools that have these kinds of call sequences, and I don't remember any problems from the third-party tools locking them. Especially when we're talking about files in $TMPDIR.

CPython without a global interpreter lock

khim — Fri, 11 Aug 2023 22:04:28 +0000

> If the GC is fast enough to immediately clean up the `fl` descriptor, then everything will work.

Nope. It wouldn't. Or, raither: it may work on your system, but if you would try to give that code to someone then pretty soon your tracker would be overflowing with messages about how nothing works. Because AV software and “security” software (like this abomination) would keep your file around for a few seconds to “investigate” it.

The only way to deal with it is to catch OSError and repeat the operation after some time (with exponential back-off). And that saves you when GC is used, too.

CPython without a global interpreter lock

Cyberax — Fri, 11 Aug 2023 16:49:11 +0000

A lot of Python code out there depends on deterministic destruction for resource cleanup. It has always been a somewhat bad idea, but it IS the case right now. Moving to a full GC will subtly break this code. For example, a sequence like this will work _most_ of the time on Windows:






def do_something(name):

  fl = open(name)

  fl.read()

  ...



do_something("blah");

os.unlink("blah");

If the GC is fast enough to immediately clean up the `fl` descriptor, then everything will work. But sometimes GC will not have time to run, and `os.unlink` will fail with a "file locked" error.

CPython without a global interpreter lock

alkbyby — Fri, 11 Aug 2023 16:10:35 +0000

I think that is one of bigger debates in our trade (e.g. recall famous paper by Boehm from as early as 90s). But as noted in this article too, refcounting is okay for fully single threaded cases (arguably, even that can be debated). But when it comes to multi-threaded cases, it quickly becomes burden. Especially if you compare with modern advanced GCs of today.

So, IMHO refcounting was and is wrong choice (for python-like use cases; e.g. kernel-space is a different matter).

(Not so) fun fact: gcc's libstdc++ still has this horrible "optimization" where shared_ptr bits detect at runtime if multi-threading is active inlined at ~every place share_ptr is copied. And compiler adds this run-time check and both single-threaded and multi-thread "atomic-ful" refcounting codes everywhere! Quick godbolt proof: https://godbolt.org/z/o9b9hxfMP

Of course this is me cherry-picking one annoying arguably performance bug in gcc. But imho it adds nicely to the topic of: "no, refcounting is not anywhere as straightforward as people tend to think".

CPython without a global interpreter lock

Karellen — Fri, 11 Aug 2023 15:30:57 +0000

Isn't ref-counting a lot more performant than GC? If you can ref-count the majority of the easy cases, and leave GC to only mop up the smaller set of hard cases which remain, isn't that going to be a big win?

CPython without a global interpreter lock

mb — Fri, 11 Aug 2023 13:19:46 +0000

One of the main problems is that the CPython C-API shall remain compatible to avoid another 2to3 scenario for all C modules.
But the C-API has reference counting baked it very deeply.

Even if you made these reference counting interfaces no-ops, then there certainly are many C modules expecting proper counting for resource freeing.

CPython without a global interpreter lock

alkbyby — Fri, 11 Aug 2023 04:00:20 +0000

Hi all. Perhaps someone could explain. Why not simply do full honest GC? All those reference counting complications go away automagically.

CPython without a global interpreter lock

NYKevin — Thu, 10 Aug 2023 16:59:44 +0000

> Reading the PEP did clarify that the plan really is as cavalier as I feared, that environment variable is a YOLO feature and it's going to be left in plain sight like a tempting red button at toddler height. I don't expect that to go well.

I know I previously said that I hoped they would provide stronger guarantees than this, but honestly, I'm having a hard time getting excited about it. If you go fiddling around with the interpreter's settings and cause your codebase to break, well, you get to keep both pieces. That's maybe not the safest way of doing things, but it's a valid perspective IMHO. This is more or less the same reasoning that leads Python to have no real encapsulation, for example.

CPython without a global interpreter lock

iabervon — Thu, 10 Aug 2023 15:18:38 +0000

Considering that the steering committee announced their intent to accept that PEP, rather than just accepting it, I expect it to get revisions from the other people who are working on the project now that it's officially the future direction.

FWIW, I think starting with schemes that are optimistic about there not being contention is the right way to go, so long as the schemes can be reworked without changing the C extension ABI. Since existing programs are generally single-threaded, there just can't be any contention in the current common case. Once there are actual programs that could perform better if contention was handled more efficiently, it'll make sense to spend peak performance on it (possibly only if the program ever spawns threads or uses a flag to get that mode without a stop-the-world event when first spawning a thread).

CPython without a global interpreter lock

tialaramex — Thu, 10 Aug 2023 12:16:35 +0000

After reading this through I think the responsibility for the muddy water lies with the PEP author.

Deferred reclamation schemes like RCU are expensive but deliver wait-freedom for readers (and typically lock-freedom for a writer). We lose peak performance but gain certainty, every one of our readers will make forward progress.

This approach, whatever it is, doesn't deliver that. It is optimistic, and when its optimism is well founded it'll go fast, when it isn't it may stall [but hopefully not deadlock?]. I think the PEP probably shouldn't mention RCU at all, or it should be in a footnote for anybody who thought "Oh, like RCU?" to clarify that you don't get RCU's guarantees. I can see why it was on the author's mind but I don't think mentioning it helps understanding.

Reading the PEP did clarify that the plan really is as cavalier as I feared, that environment variable is a YOLO feature and it's going to be left in plain sight like a tempting red button at toddler height. I don't expect that to go well.

CPython without a global interpreter lock

Paf — Thu, 10 Aug 2023 02:29:11 +0000

I know some folks involved in this are reading this, so:

This is really remarkable work. Congratulations to those doing it.

CPython without a global interpreter lock

andresfreund — Wed, 09 Aug 2023 23:10:52 +0000

Nice summary!

> This proposal relies on a scheme that mostly avoids acquiring locks when accessing individual elements in lists and dictionaries. Note that this is not “lock free” in the sense of “lock-free” and “wait-free” algorithms that guarantee forward progress. It simply avoids acquiring locks (mutexes) in the common case to improve parallelism and reduce overhead.

I do wish the terminology around this wasn't overloaded...