[Tim] > allocating containers "in the middle" of something else is > actually rare. [Neil Schemenauer] > It looks like you and Guido are working on a solution to avoid > doing this. Wouldn't it be better to change the GC so that it > was okay to do that? Specifically, I'm thinking of making > collection only happen between opcodes. Perhaps that is too > large of a change to make before the release. Changing PyDict_Next() and PyDict_SetItem() to avoid gratuitous reshuffling is a worthy goal regardless (merely traversing a dict simply "should not" resize it, and has caused problems independent of gc), so I'm solidly +1 on those. Loops using PyDict_Next() to mutate values of existing keys can also cause __del__ methods to execute (because of decref'ing the old values), so there are non-gc vulnerabilities there too we haven't really addressed -- and then even switching to "between opcodes" gc wouldn't stop the problems unique to gc (since __del__ methods go back to the eval loop). But "between opcodes" sounds like a promising idea to me to short-circuit the mass of other potential problems that can't be triggered by just decref'ing things. Where's the PEP <wink>?
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