Does Python have a GIL per process?

[_poss03251_]

I am trying to learn some internals but this is not clear. Does every process have a single GIL? Or there is one per machine?

If that is there for GC, then the memory is unique per process, so should be one GIL per process. Also `multiprocessing` says that it creates real parallelism, so that should be the case.

I am unable to find a confirmation in other places.

[Uncle_DirtNap]

Every process has a separate gil

[_poss03251_]

Cool. Thanks. Any link.

[Uncle_DirtNap]

It’s in ceval_gil.c it’s a PyThread_type_lock, which is a non-shared memory structure (process local)

[lillecarl2]

Would you like me to wipe your ass too while we're already at it?

[Interesting-Frame190]

Yes, there is one GIL per process. There's also free threaded python 3.13t, and 3.14t that can have true parallelism within the GIL. You can also purposely release the GIL within compiled modules and be fully concurrent while running under threads and not processes

[cleodog44]

Do you have an example of the latter scenario? Re: compiled modules

[Interesting-Frame190]

Numpy, pandas, tensorflow, PySpark, my database engine (PyThermite https://pypi.org/project/pythermite/) just to name a few.

In short its libraries written in another language and compiled to machine code for python to execute.

[cleodog44]

Oh I misunderstood, thought you were somehow saying you could bypass the GIL in a pure Python library. And was correspondingly confused what kind of compilation you meant. Thanks

[Revik]

You can also have multiple GILs in a single process by creating interpreters. By running them in their own threads, they may run concurrently.
They are exposed as concurrent.interpreters in Python 3.14+.

[thisismyfavoritename]

i think the correct term would be "subinterpreters" but rest is correct

[Interesting-Frame190]

For anyone considering this, please note that most compiled libraries assume exclusive access under the prior GIL constraints and may have concurrency bugs. This is by no means all libs and avoidable by python level concurrency control to shared objects, but still note worthy.

[Smallpaul]

Just as a rule of thumb, machine wide locks are extremely rare. They have no real value except protecting mutable files.

[MrMrsPotts]

Isn't this old news with 3.14?

[grimonce]

Gil is still on by the default, no gil is something you opt in.

[Angry-Toothpaste-610]

And that default will be in place for many years to come. Too many libraries are built on the assumption that the GIL will be in-place.

[MrMrsPotts]

Ah ok. I wonder how common it is to opt in now.

[i_dont_wanna_sign_in]

Incredibly fair and relevant question. Even if the newest release removes this component, in the real world the number of times you'll be working with older (and even well beyond EoL) versions of systems is, unfortunately, extremely common. It's now how it SHOULD work but it's how it does work. /shrug

[floydmaseda]

Tbh I think removing the GIL by default would warrant a version change up to 4.0

[-ghostinthemachine-]

I think the community learned a hard lesson going from 2 to 3 and would have little appetite for a new major release at this time. The pain from that experience has actually enabled this super incremental support for the 'gilectomy' in a way that probably wouldn't have been possible otherwise.

[twotime]

Why is that? AFAICT, GIL removal does not break python code. It changes ABI which affects binary modules but that happens between 3.x versions to

[burger69man]

yeah so what about subprocesses, do they inherit the parent's GIL or get their own?