It's in the "Py_mod_gil Slot" section [0] in the PEP:

> In --disable-gil builds, when loading an extension, CPython will check for a new PEP 489-style Py_mod_gil slot. If the slot is set to Py_mod_gil_not_used, then extension loading proceeds as normal. If the slot is not set, the interpreter pauses all threads and enables the GIL before continuing. Additionally, the interpreter will issue a visible warning naming the extension, that the GIL was enabled (and why) and the steps the user can take to override it.

[0] https://peps.python.org/pep-0703/#py-mod-gil-slot

Here's what's puzzling me about this:

Why then is there even a need for a seperate nogil build? If it is like this says, wouldn't it be easier to just make the standard build switch to gil or nogil automatically (or honor the users choice).

The fact that the SC thinks having two versions suggests there is more complexity involved than this section of the PEP leads readers to believe.

You have to recompile your C extensions for the nogil build. Consider an application where one thread is calling xs.append from a C extension and another is calling xs.pop and xs[-1] on the same list object xs. In the nogil build these operations need to use a fine-grained lock on xs, and in the gil build these are thread-safe due to each thread holding the GIL when it does these operations.

On top of that, some of the list and dictionary operations are available to extensions as C macros to avoid the overhead of a C function call.

However, it looks like the nogil build will be able to run in "GIL mode" for maximum compatibility, including switching to GIL mode partway through execution, but I'm expecting this to be slower than running the gil build in GIL mode.

> However, it looks like the nogil build will be able to run in "GIL mode" for maximum compatibility, including switching to GIL mode partway through execution

Yes, that's what they were asking about. Why have two versions for a mode switch. Everything you explained before that is irrelevant, I'm afraid.

> but I'm expecting this to be slower than running the gil build in GIL mode.

That could be the answer to their question, but that's not definitive enough.

1. The "stable ABI" is broken on nogil, the selling point of the stable ABI was "add this C preprocessor flag and your extension will work on all future CPython versions, after paying a speed penalty". This is useful for eg closed source extensions. If the nogil build was the only build available, these extensions would require recompilation.

2. There are a lot of users that want fast Python and a lot of effort was put in to optimise it. I think the core team wouldn't want to release and expect everybody to use a version which regresses in performance, for a feature (nogil) which most won't be able to use due to using C extensions which haven't had nogil-supporting code changes.

> The "stable ABI" is broken on nogil, the selling point of the stable ABI was "add this C preprocessor flag and your extension will work on all future CPython versions, after paying a speed penalty". This is useful for eg closed source extensions. If the nogil build was the only build available, these extensions would require recompilation.

It looks for a flag, if it doesn't see it then it turns the GIL on.

Where is the need for recompilation?

> I think the core team wouldn't want to release and expect everybody to use a version which regresses in performance

But you're just guessing that it's slower in GIL mode, aren't you?

"Where is the need for recompilation?"

https://docs.python.org/3/c-api/typeobj.html#c.PyObject.ob_r...

The stable ABI lets extensions access the reference count of any object directly. I don't know why. Normally the functions Py_IncRef and Py_DecRef should be sufficient. Objects no longer have a single number as their reference count.

Edit: In Python 3.2-3.9, the stable ABI included Py_INCREF, the C macro.

https://docs.python.org/3/c-api/type.html#c.PyType_FromModul...

The stable ABI lets extensions create new Python types. These can override tp_alloc field to use custom memory allocators when instances of the type are instantiated. The custom memory allocator needs to initialise the reference count to 1.

> But you're just guessing that it's slower in GIL mode, aren't you?

There are new implementations with per-object locks of list.append, dict.__setitem__ etc. These are incredibly common operations in Python code. These inherently will be more complicated than the previous implementation, meaning more instructions and slower. So there needs to be a branch at the start of list.append of whether to go to the old gil implementation or the new nogil one. Adding a branch so frequently will inherently make the runtime slower.

Now with a lot of work these can be optimised and the speed penalty reduced, but CPython goes on an annual release cycle. If the nogil code is held as a fork of the CPython repository without being merged in, until it reaches a performance goal, that brings other issues.

> Objects no longer have a single number as their reference count.

Does that stay true once the GIL turns back on?

> These can override tp_alloc field to use custom memory allocators when instances of the type are instantiated. The custom memory allocator needs to initialise the reference count to 1.

I'm not following why this affects ABI compatibility, sorry.

> So there needs to be a branch at the start of list.append of whether to go to the old gil implementation or the new nogil one. Adding a branch so frequently will inherently make the runtime slower.

I don't know about that. CPUs handle always-taken and never-taken branches very well.

> Does that stay true once the GIL turns back on?

In the current nogil implementation, AFAICS, it seems the GIL can't be turned back on so there is no answer yet.

Theoretically, you could have a one-off operation which fixes all objects when the GIL is turned on. However, there's no way to get all objects in Python. gc.get_objects() only returns tracked objects, and there is no way to list untracked objects.

It seems, three fields are exposed on every CPython object in the stable ABI, any change which affects their offsets will break the stable ABI. https://github.com/capi-workgroup/problems/issues/4#issuecom...

> I'm not following why this affects ABI compatibility, sorry.

True, PyType_FromSpec can set tp_alloc to a wrapper function which papers over the difference in what the "allocfunc" should initialise the memory to.

Re performance - merging the change is the only way people will actually start targeting nogil.

> I don't know about that. CPUs handle always-taken and never-taken branches very well.

and dynamic patching is also an option.

I'm not sure if the stable ABI is really like... going to stick around. Python 3.11 deprecated numerous functions in it mostly around interpreter configuration (the new PyConfig and PyPreConfig APIs are by definition not ABI stable), and the last couple releases have shown that deprecations in Python do mean it'll be removed later. The question then is whether they'll drop these APIs with a 3.x release (which would break the entire preomise of the stable ABI) or during a bump to 4.x. It really ought to be the latter and I suspect Python 4.x is going to remove the entire notion of stable ABI.

In either case it seems obvious now that there is likely no point bothering with the stable ABI any more.

Because it's being prudent. With such a big project, the unknown unknowns are numerous.

Something nobody though about lurks in this nogil build, and we are only going to find out when it goes to prod and users report about it.

Instead of breaking the entire Python community's code, the risk is opt-in for a few years.

Thanks. Glad to know now!