Queue cleanup

Lawrence D'Oliveiro 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;
    do /*once*/
      {
        TheBufferInfo = PyObject_CallMethod(FromArray, "buffer_info", "");
        if (TheBufferInfo == 0)
            break;
        AddrObj = PyTuple_GetItem(TheBufferInfo, 0);
        LenObj = PyTuple_GetItem(TheBufferInfo, 1);
        if (PyErr_Occurred())
            break;
        Py_INCREF(AddrObj);
        Py_INCREF(LenObj);
        *addr = PyInt_AsUnsignedLongMask(AddrObj);
        *len = PyInt_AsUnsignedLongMask(LenObj);
        if (PyErr_Occurred())
            break;
      }
    while (false);
    Py_XDECREF(AddrObj);
    Py_XDECREF(LenObj);
    Py_XDECREF(TheBufferInfo);
  } /*GetBufferInfo*/

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 mailing list