Is the Python GIL really per interpreter?

前端 未结 3 1574
孤街浪徒
孤街浪徒 2021-02-07 22:29

I often see people talking that the GIL is per Python Interpreter (even here on stackoverflow).

But what I see in the source code it seems to be that the GIL is a global

相关标签:
3条回答
  • 2021-02-07 23:08

    I believe it is true (at least as of Python 2.6) that each process may have at most one CPython interpreter embedded (other runtimes may have different constraints). I'm not sure if this is an issue with the GIL per se, but it is likely due to global state, or to protect from conflicting global state in third-party C modules. From the CPython API Docs:

    [Py___Initialize()] is a no-op when called for a second time (without calling Py_Finalize() first). There is no return value; it is a fatal error if the initialization fails.

    You might be interested in the Unladen Swallow project, which aims eventually to remove the GIL entirely from CPython. Other Python runtimes don't have the GIL at all, like (I believe) Stackless Python, and certainly Jython.

    Also note that the GIL is still present in CPython 3.x.

    0 讨论(0)
  • 2021-02-07 23:17

    Perhaps the confusion comes about because most people assume Python has one interpreter per process. I recall reading that the support for multiple interpreters via the C API was largely untested and hardly ever used. (And when I gave it a go, didn't work properly.)

    0 讨论(0)
  • 2021-02-07 23:20

    The GIL is indeed per-process, not per-interpreter. This is unchanged in 3.x.

    0 讨论(0)
提交回复
热议问题