> I think you'd have better luck with a patch that bounded the sizes of these > free lists. That's not hard to do; e.g., look at the simple bounded free > list in frameobject.c. I wouldn't like a small limit on ints or floats, but > letting any subsystem suck up unbounded resource forever does cause > problems. Unfortunately the limit code would be much more complex than in frameobject because frameobject does not allocate in blocks. So, we would have to somehow determine if an int block is completely free before freeing it. Some different methods: 1) Scan each block and count the number of free integers. If the block contains only free integers, then free it. This would essentially be the code in PyInt_Fini(). We actually have code that calls PyInt_Fini when we are doing leak detection. 2) Alternate to #1, it could avoid scanning entire blocks if it detected a used int, and instead manually dissect the free_list iff the entire block is free instead of rebuilding free_list from scratch like PyInt_Fini() does. 3) Add a counter of the number of free ints in PyIntBlock. Free the block with this number equals the maximum number of ints in a block. The problem with #1 is that it is slow, and one would need to determine how often to call it. #2 has the same problem. #3 is a little nicer, at the cost of maintaining the counter (which should be negligible). Thoughts? -Eric
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