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