[capi-sig] is deinitialisation of embedded python equal to fullrestart?

Alexey Nezhdanov snakeru at gmail.com
Fri Jul 13 13:45:43 CEST 2007


On Friday 13 July 2007 14:29, Hrvoje Niksic wrote:
> Alexey Nezhdanov <snakeru at gmail.com> writes:
> > The most essential for me is freeing all sorts of RAM that python
> > allocated for objects or whatever else.
>
> Reinitializing Python should work, but it might not produce the effect
> you expect.
>
> Python allocates memory using the underlying C functions such as
> malloc.  Shutting down the interpreter simply makes Python call free
> on the memory segments that belong to Python objects.  Because of the
> way malloc and free work, doing that is no guarantee that memory will
> be returned to the operating system.  free() only guarantees that the
> memory will be marked as usable for unspecified later calls to malloc.
> Some malloc implementations go one step further and actually return
> the memory to the system, but that is only possible when freeing the
> block(s) at the very end of the region, so you cannot rely on it.
>
> At the end of the day, your process will probably not decrease in
> memory footprint; however, it will not grow on further allocations
> because it will reuse the freed memory.  But, barring a bug in Python,
> that is exactly the situation you would be in if you didn't
> reinitialize the interpreter in the first place.
ok, thanks. Still it may be ok for my purposes if I can keep python from 
growing forever and just keep it beneath some limit.
Also, as I understand - memory that is marked as available for reuse will be 
swapped out if need for RAM will arise.

> > IOW - I want python to be returned in virgin state as it was on my
> > program load w/o exiting my program and closing all files/tcp
> > connections that it have opened/or resetting any of other my C data
> > structures that were created.
>
> Doesn't Python automatically close open files when the script
> finishes?
Yes, it does. But I meant files that are opened by C part of the program.

-- 
Respectfully
Alexey Nezhdanov


More information about the capi-sig mailing list