Idea for removing the GIL...

[Carl Banks]

On Feb 8, 11:49 am, John Nagle <na... at animats.com> wrote:
>     The real reason for the GIL, though, is to support dynamic
> code modification in multi-thread progrems.  It's the ability
> to replace a function while it's being executed in another thread
> that's hard to do without a global lock.  If it were just a data-side
> problem, local object locks, a lock at the allocator, and a
> concurrent garbage collector would work.

I realize that you believe that Python's hyper-dynamicism is the cause
of all evils in the world, but in this case you're not correct.

Concurrent garbage collectors work just fine in IronPython and Jython,
which are just as dynamic as CPython.  I'm not sure why you think an
executing function would be considered inaccessible and subject to
collection.  If you replace a function (code object, actually) in
another thread it only deletes the reference from that namespace,
references on the executing stack still exist.

The real reason they never replaced the GIL is that fine-grained
locking is expensive with reference counting.  The only way the cost
of finer-grained locking would be acceptable, then, is if they got rid
of the reference counting altogether, and that was considered too
drastic a change.


Carl Banks