PEP 703: Making the Global Interpreter Lock Optional (3.12 updates)

[colesbury (Sam Gross)]

@pf_moore

Suppose I had a library that contained this function:

def sum_list(l):
    total = 0
    for n in l:
        total = total + n
    return total

who ensures (whether by auditing or explicit locking) that the input list isn’t being mutated while the function code is running? If sum_list can’t make that assumption, doesn’t it need a lock? Or am I misunderstanding nogil totally?

The GIL does not prevent modification to the list l. If your Python code did not need a lock with the GIL, it won’t need a lock for nogil. Of course, if your Python code needed a lock even with the GIL, it will still need a lock with nogil.

@brettcannon

You could get that with concurrent.futures.Executor.map() and using the ThreadPollExecutor, but I don’t know what level of guarantees there are about race conditions (e.g., reading from a dict and then writing to it again for the same key across two threads; can one write blindly overwrite the other?).

If multiple threads write to the same key of the same dict, then one thread will overwrite the value written by the other thread. This is true both with the GIL and in the nogil implementation.