ldo at geek-central.gen.new_zealand
Mon Aug 30 05:57:58 CEST 2010
In message <7x4oeftuk4.fsf at ruckus.brouhaha.com>, Paul Rubin wrote:
> I'd say [reference-counting is] not real gc because 1) it's unsound
> (misses reference cycles), and 2) it requires constant attention from the
> mutator to incr and decr the reference counts. So developing modules for
> the CPython API means endlessly finding and fixing refcount bugs that lead
> to either crashes/security failures, or memory leaks.
I don’t see why that should be so. It seems a very simple discipline to
follow: initialize, allocate, free. Here’s an example snippet from my DVD
Menu Animator <http://github.com/ldo/dvd_menu_animator>:
static void GetBufferInfo
PyObject * FromArray,
unsigned long * addr,
unsigned long * len
/* returns the address and length of the data in a Python array object. */
PyObject * TheBufferInfo = 0;
PyObject * AddrObj = 0;
PyObject * LenObj = 0;
TheBufferInfo = PyObject_CallMethod(FromArray, "buffer_info", "");
if (TheBufferInfo == 0)
AddrObj = PyTuple_GetItem(TheBufferInfo, 0);
LenObj = PyTuple_GetItem(TheBufferInfo, 1);
*addr = PyInt_AsUnsignedLongMask(AddrObj);
*len = PyInt_AsUnsignedLongMask(LenObj);
It’s quite easy to assure yourself that this is never going to leak memory.
More complicated examples can simply nest constructs like these one within
the other to arbitrary depth, while still giving the same assurance at every
level. In short, this technique scales well.
> If you program the Java JNI or a typical Lisp FFI, you'll find that real
> gc is a lot simpler to use since you avoid all the refcount maintenance
> hassles. You allocate memory and shut your eyes, and the gc takes care of
> freeing it when it figures out that you are done.
And how do you run such an application? You have to limit it to a
predetermined amount of memory to begin with, otherwise it would easily
gobble up everything you have.
In the old days of “classic” MacOS, every application had to run in a fixed-
size application heap. I have no wish to return to those days.
More information about the Python-list