On Wed, Jul 12, 2000 at 01:05:52AM -0400, Barry A. Warsaw wrote: >... > I suspect this is exactly what's happening. I'd have to spend more > time to know exactly what's happening, but this jives with the > observed behavior. If so, the only thing we could do is try to break > the cycles manually at shutdown time and have the normal decrefs free > all the memory. > > I'm not sure it's worth the effort. 1) it isn't much memory; 2) it > only leaks when gc is disabled; 3) it's a one time cost, not > e.g. a leak every time you spawn a thread. > > That last is interesting, because I believe at least on Solaris, there > /is/ a leak for each new thread, but I haven't had time to find it > yet. That one's worth tracking down. For the others, it's actually > quite nice to see gc doing it's job! > > Other than that, running the test suite, the current CVS seems to have > a very clean bill of health memory usage-wise. Please try to consider the embedded case, too. If Python interpreters are created/destroyed, or modules are loaded/thrown out, or whatever... are there leaks? Any leak can be a disaster in embedded cases. Now... no need to be defensive :-) ... just pointing out there is another consideration when thinking about leaks. Cheers, -g -- Greg Stein, http://www.lyra.org/
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