[Python-Dev] Python 2.3a1's mandatory use of cyclic GC causes existing applications to fail (original) (raw)

Tim Peters tim.one@comcast.net
Wed, 05 Feb 2003 11:32:34 -0500

[Michael Hudson]

I'm not fully aware of all the issues, but I think that the interaction between the sometimes-there-sometimes-not gc code and the trashcan facility for safely deallocating deeply nested structures was deeply confusing and was a motivation for making the GC code non-optional.

That's so, and the trashcan code was the source of critical bugs. The trashcan code is nearly obvious when we can rely on gc being there, and extension modules can easily use the trashcan machinery too. In the absence of cyclic gc, extension modules can't use the trashcan machinery without editing the core Python source code to teach the trashcan about each type that wants to participate, and the trashcan implementation was much harder to get right (it took us years to get to the state where we thought it might finally be right ).

So desirable or not, re-adding --without-cycle-gc may be hard.

It would be, yes. Note too that --without-cycle-gc was never intended to be an ongoing config option. It was a hairy experimental feature at first, and we wanted a way to back it out quickly if the design proved to have fatal flaws. That didn't happen.