[Tim] >> Another scheme is to just run all the weakref callbacks associated >> with trash cycles, without tp_clear'ing anything first. Then run gc >> again to figure out what's still trash, and repeat until no more >> weakref callbacks in trash cycles exist. If the weakref >> implementation is changed to forbid creating a new weakref callback >> while a weakref callback is executing, that gc-loop must eventually >> terminate (after the first try even in most code that does manage to >> put weakref callbacks in trash cycles). [Michael Hudson] > Maybe I'm misunderstanding, but in the presence of threads might that > not create much confusion? I'm envisaging > > 1) object reaches refcount 0 > 2) weakred callback gets called > 3) thread switch happens > 4) new thread attempts to create a weakref callback, which fails > 5) programmer goes insane > > Or am I missing something? Nope -- it's a downside to that scheme, probably fatal.
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