Re: freeing the memory of a casted object ? [SEC=PERSONAL]
"Diez B. Roggisch" <[email protected]> Thu, 23 Jun 2011 10:50:29 +0200
| Newsgroups | gmane.comp.python.ctypes |
|---|---|
| Organization | Me, Myself & I |
| Message-ID | <[email protected]> |
On Thursday, June 23, 2011 10:49:04 am Andrew MacIntyre wrote: > [apologies for top post] > > On Windows 7 32bit, Patricio's code triggers a MemoryError when it exhausts > the heap. gc is not kicking in here, as the number of deallocations isn't > sufficient to trigger it; reduce the buffer size to 1MB (and ditch the > sleep) and gc does in fact kick in. > > I think it comes down to the cast() function doing more under the covers > than is explained in the docs, as it would appear that cast() results in > an extra (weak?) reference being kept back to the original buffer. > > This protectionism results in reference cycles, which gc.collect() can > clean up. This was probably to make certain operations feasible without > lots of explicit references needing to be kept; see the type conversions > section of the ctypes tutorial for an example that wouldn't work as > intended/desired without this behind-the-scenes reference keeping. > > Rather than routinely calling gc.collect(), tuning the gc thresholds for > the particular usage pattern might be more attractive. Either way, this > is a case where actively using the gc module is required. I have to admit that I was a little bit premature in my assesment of the situation - I later found out that the memory problem actually *did* occur without the gc.collect() call - it just took longer. I wanted to post that, but got distracted. Sorry for the confusion. Diez ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev