A Steering Council notice about PEP 703 (Making the Global Interpreter Lock Optional in CPython)
discuss.python.org
Posting for the whole Steering Council, on the subject of @colesbury’s PEP 703 (Making the Global Interpreter Lock Optional in CPython). Thank you, everyone, for responding to the poll on the no-GIL proposal. It’s clear that the overall sentiment is positive, both for the general idea and for PEP 703 specifically. The Steering Council is also largely positive on both. We intend to accept PEP 703, although we’re still working on the acceptance details. As we’ve done a few times in the past, we ...

Meta is dedicating 3 engineers to get the nogil patches into cpython. There are some other companies stepping up as well. This is huge this is the closest we have ever been to solving the issue of the GIL.

  • teraflopsweat@lemm.ee
    6·
    1 year ago

    As a filthy casual, could anyone give me a link or brief summary as to why the GIL should/shouldn’t go away?

    • Dogeek
      2·
      1 year ago

      The GIL is a thread lock. It prevents threads from accessing the same memory space, eliminating race conditions and more importantly, keeping the reference counters correct so that the python garbage collector can correctly free memory (avoiding leaks)

    • Rev@ihax0r.comOPEnglish
      1·
      1 year ago

      Like cython?

      Its a whole lot of magic. I many times have to look at the generated c code because its doing something weird especially when generating c++