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