On Feb 8, 11:49 am, John Nagle <na...@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 -- http://mail.python.org/mailman/listinfo/python-list
