On 2016-01-20 2:45 PM, Glenn Linderman wrote: > For the reuse case, can't you simply keep the ma_version "live" in > dict items on the free list, rather than starting over at (presumably) > 0 ? Then if the dict is reused, it bumps the ma_version, and the > fallback code goes on with (presumably) relocating the original dict > (oops, it's gone), and dealing with the fallout. Not all dicts are created from a freelist, and not all dicts go to the freelist when they are GCed. You still can have this situation: - dict "A" is used as f_locals for a frame, its ma_version is set to X - dict "A" is GCed, but the freelist is full, so it's just freed - after a while, you call the code object, a new dict "B" is allocated with malloc (since now the freelist happens to be empty) for f_locals - it happens that "B" is allocated where "A" was, and its ma_version happens to be X by an accident > > Then you can use the regular dict id as the globally unique dict id? > And only need the one uint64, rather than a separately allocated extra > pair of uint64? In my design only namespace dicts will have a non-NULL ma_extra, which means that only a fraction of dicts will actually have a separated pair of uint64s. I think that we should either use one global ma_version (as Maciej suggested) or ma_extra, as it gives more flexibility for us to extend dicts in the future. A global (shared between all dicts) unit64 ma_version is actually quite reliable -- if a program does 1,000,000 dict modifications per second, it would take it 600,000 years till wrap-around. Yury
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