New PEP: A Per-Interpreter GIL

[ericsnowcurrently]

This is an informational PEP explaining the issues and work around making the GIL per-interpreter.

(I hope to publish/post later this week, but figured I'd get the meat of it up now so I can point people at it.)

[brettcannon]

Does this really need to be a PEP if it is just basically going to be a white paper trying to justify a per-interpreter GIL (which has not been approved to occur)?

[gvanrossum]

I don't have an opinion yet on whether this particular document should be a PEP or a white paper, but I think there are two decisions ahead of us that *do* require a PEP (maybe one PEP together?): - Are we going to implement a per-interpreter GIL? - Should we adopt immortal objects? The (IMO strong) connection between the two is that if we have a per-interpreter GIL we cannot share *any* objects between interpreters unless we make all such objects immortal (and immutable). And while we have some possible hacks that could enable per-interpreter GIL without immortal objects, they are not pretty and pose a risk for ABI and API compatibility. OTOH immortal objects have a certain cost associated with them. Of course another, related decision is what to do with Sam Gross's nogil work. And yet another issue to decide is, *if* we get a per-interpreter GIL, what API to use to share data between interpreters (since you can't share mutable objects). This is covered by PEP 554, but that hasn't been accepted yet, and arguably the API there is a bit baroque. Presumably all these things have to be discussed by the SC. Would it require a PEP to get them on the SC agenda? If so, we had better get cracking, or none of this will make it into 3.11. Some guidance from the SC (on the meta-issue of whether PEPs are required and who is expected to write them) would be appreciated.

…

On Thu, Jan 6, 2022 at 2:26 PM Brett Cannon ***@***.***> wrote: Does this really need to be a PEP if it is just basically going to be a white paper trying to justify a per-interpreter GIL (which has not been approved to occur)? — Reply to this email directly, view it on GitHub <#2212 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWCWMTBGJSPY36ZP67MY33UUYJKLANCNFSM5LIRDSCA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

[corona10]

Maybe we can add this issue too.
https://bugs.python.org/issue1635741

[warsaw]

Does this really need to be a PEP if it is just basically going to be a white paper trying to justify a per-interpreter GIL (which has not been approved to occur)?

On this narrow question, given that we don't have any other good repository for these types of documents, it doesn't bother me for things like this to be information PEPs. And even so, if they weren't PEPs, how would they be discoverable?

[encukou]

I'm under the impression that an informational PEP is essentially a whitepaper. What PEP 1 says looks like a definition of a whitepaper. (Or is my English failing me and we're talking about a different meaning of the term?)
Of course, an informational PEP cannot be approved, so it's not the only PEP you'll need to make big changes to the language. The "proposal" section would be better named "plan" or "goals".

[vstinner]

IMO this topic is too wide to fit everything into a single PEP. I suggest to split it into multiple (smaller) PEPs:

• Rationale for running multiple interpreters in parallel: focus on use cases, performance
• Guideline to make things per-interpreter. Note: I don't think that a PEP should track the progress of such work.
• Address the complex problem of static types
• Address the complex problem of singletons
• Make the GIL per interpreter: elaborate the impact on C extensions, explain how to migrate existing C extensions to that, propose a solution to continue supporting C extensions which are "compatible"

For static types and singletons, it seems like you are supporter of immortal objects. Well, I dislike immortal objects and there are other solutions to these problems. For example, make singletons per interpreter, and keep static types in the main interpreter, but modify C extensions to call functions to get types, in C extensions which needs to be compatible with sub-interpreters (all stdlib extensions must be modified this way).

IMO the key is the migration plan. How to introduce this feature without requiring all C extensions to be written on a flag day? It has been discussed multiple times to add a flag to a C extension to opt in for sub-interpreters support.

Moreover, IMO we should also consider to support multiple interpreters sharing the same GIL ("shared GIL", current behavior) and interprereters having their own GIL ("isolated"). Again, it's to have a more smooth migration plan, to avoid having to rewrite all C extensions on a flag day.

[ericsnowcurrently]

Does this really need to be a PEP if it is just basically going to be a white paper trying to justify a per-interpreter GIL (which has not been approved to occur)?

Yeah, after the conversation here it makes sense to me to split the PEP into the decidable parts (and maybe not even do an informational PEP).

[gvanrossum]

• Rationale for running multiple interpreters in parallel: focus on use cases, performance

This could be split into two parts:

• Rationale for multiple interpreters while GIL remains shared
• Rationale for multiple interpreters with separate GILs

And we should probably address the downsides of separate GILs:

• Can only share immutable immortal objects
• Issues for ABI and API compatibility

[ericsnowcurrently]

• Rationale for running multiple interpreters in parallel: focus on use cases, performance

This would be good and would benefit PEP 554 as well. However, I'm worried that I don't have enough time to do all these PEPs at once and still get anything else done. This PEP doesn't seem like it would add enough value to make it worth it. (The general points would just go into other PEPs, with not as much detail.)

• Guideline to make things per-interpreter. Note: I don't think that a PEP should track the progress of such work.

To me, the devguide would be a better place for this.

Aside from guidelines for the transition to per-interpreter, we would also need to cover any constraints core devs need to keep in mind relative to subinterpreters. We would also document any related tooling, e.g. c-analyzer (if that survives). This information would be valuable well after the GIL becomes per-interpreter.

• Address the complex problem of static types
• Address the complex problem of singletons

Why would these be separate PEPs?

• Make the GIL per interpreter: elaborate the impact on C extensions, explain how to migrate existing C extensions to that, propose a solution to continue supporting C extensions which are "compatible"

This is basically already covered by PEP 630.

For static types and singletons, it seems like you are supporter of immortal objects. Well, I dislike immortal objects and there are other solutions to these problems. For example, make singletons per interpreter, and keep static types in the main interpreter, but modify C extensions to call functions to get types, in C extensions which needs to be compatible with sub-interpreters (all stdlib extensions must be modified this way).

That's pretty much exactly what I was planning on until recently. 🙂 At first I looked into immortal objects because they solve the problem so much more simply. However, there didn't seem to be a good way to work around the performance penalty. So I focused on per-interpreter objects (and successfully prototyped most of it).

However, now immortal objects may be possible without the penalty. I'm going to do some benchmarking on the current branch. If they work out then I'd rather go with that because it is so much simpler.

Either way we should consider deprecating all the objects in the C-API, and provide lookup functions as a replacement.

IMO the key is the migration plan. How to introduce this feature without requiring all C extensions to be written on a flag day?

No extensions will need to be rewritten. In subinterpreters created via Py_NewInterpreter(), extensions that currently work will keep working. Those that don't currently work there will still not work.

If an extension wants to be used in subinterpreters that do not share a GIL, they would have to be isolated (PEPs 489/630) first. However, that would be new in 3.11, so there is not compatibility issue. Existing code will keep working.

It has been discussed multiple times to add a flag to a C extension to opt in for sub-interpreters support.

PEP 489 says that if an extension implements multi-phase init then it must support subinterpreters (and reloading, etc.).

Moreover, IMO we should also consider to support multiple interpreters sharing the same GIL ("shared GIL", current behavior) and interprereters having their own GIL ("isolated").

That is exactly the plan. Py_NewInterpreter() will continue creating subinterpreters that do share a GIL.

[JelleZijlstra]

FYI, PEP 679 is now taken.

[brettcannon]

The SC talked about this and if you want to move forward with an informational PEP that outlines plans, @ericsnowcurrently , then that's fine. We do want to be very clear, though, that it doesn't give tacit approval for the idea, just a place for you to collect and write down what you want to accomplish and how you plan to pull it off.

We may also to move/copy it somewhere else in the future as we are now talking about how to handle communication of these large projects.

[ericsnowcurrently]

I'll be posting a PEP just about immortal objects soon, as well a more focused one about per-interpreter GIL. Both will be leaner this this one.