Circular references (was: Defining VCL-like framework for Py

Gordon McMillan gmcm at hypernet.com
Tue May 25 00:34:19 EDT 1999


William Tanksley wrote:

> On Thu, 20 May 1999 15:00:03 -0500, Gordon McMillan wrote:
> 
> >Despite these drawbacks, I generally prefer ref counting to garbage
> >collection. GC is generally nondeterminant - you know it _will_
> >happen, but you have no idea _when_. So if your objects have some
> >kind of outside resource open, you need to have a special free()
> >method anyway instead of relying on freeing it in the destructor. 
> 
> I prefer refcounting as well -- it feels like a simpler, more
> controlled solution.  It's not particularly "more deterministic",
> though; any assignment to a pointer can result in a massive flurry
> of deallocations :).  

I said "deterministic", not "easily predicted" <wink>.

> Ken Thompson recently mentioned the way they
> do GC in Inferno.  They keep reference counts, and also do a lazy
> generational scan every once in a while.  The reference counting
> controls the vast majority of the garbage; the lazy scan eventually
> finds and cleans up the occasional cycle, without spending too much
> time or causing too many other problems. It looks like a nice
> solution to the problem of cycles.

I read that interview, too, and was very intrigued by that section.

> >I realize many people feel strongly the other way, and I'm not going 
> >to fight about it. Neither solution is perfect. I'm just stating my 
> >preference.
> 
> Well, I agree -- but I would like to remove the problem of cycles. 
> It would just be one less thing to complicate my Python code.

Maybe we can fight about something else then?
 
> I've tried to find other methods, but nothing simple seems to work
> well -- everything requires some pretty nasty complications and
> overhead.

In some languages, circular references make it hard to compile, let 
alone clean up nicely.

there's-a-hole-in-the-bucket-ly y'rs

- Gordon




More information about the Python-list mailing list