Python PEP for Making the GIL Optional Doesn't Get Enough Support

Re:Python PEP for Making the GIL Optional Doesn't Get Enough... by debugnik on Thursday June 08, 2023 @06:17AM (#36239547)

They should consider copying OCaml's solution to the GIL: sets of one or more threads ("domains"), each set with its own global lock.

So old code spawns threads on the current domain, behaving as before, but new code can spawn new domains instead for proper concurrency. This lets you contain GIL-dependent threads while progressively migrating away from the GIL.

[ Parent | on HN ]

Re:Python PEP for Making the GIL Optional Doesn't Get Enough... by jononor on Sunday June 11, 2023 @07:57PM (#36286992)

PEP 684 – A Per-Interpreter GIL https://peps.python.org/pep-0684/

[ Parent | on HN ]

Re:Python PEP for Making the GIL Optional Doesn't Get Enough... by debugnik on Saturday June 17, 2023 @10:11AM (#36370302)

This is a good and necessary step in the right direction, but if I understand correctly interpreters can't share memory directly. So this will unblock some uses cases for embedding Python and for replacing process-level parallelism, but it doesn't yet improve their existing threading model.

Nice to know anyway, I'll keep an eye on how they progress.

[ Parent | on HN ]