2016-04-15 0:22 GMT+02:00 Brett Cannon <brett at python.org>: > And even if it was GIL-free you do run the risk of two dicts ending up at > the same version # by simply mutating the same number of times if the > counters were per-dict instead of process-wide. For some optimizations, it is not needed to check if the dictionary was replaced, or you check it directly. So it doesn't matter to have the same version with the same number of operations. For the use case of Yury's optimization, having a globally unique version tag makes the guard much cheaper, and the guard must check that the dictionary was not replaced. IMHO it's cheap enough to make the version globally unique. I don't see any technical drawback of having a globally unique version. It doesn't make the integer overflow much more likely. We are still talking about many years before an overflow occurs. -- When we will be able to get ride of the GIL for the dict type, we will probably be able to get an atomic "global_version++" for 64-bit integer. Right now, I don't think that an atomic int64++ is available on 32-bit archs. Victor
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4