Re: [Python-Dev] Linus on garbage collection
Michael Foord wrote:
On 06/05/2011 18:26, Mark Shannon wrote:
On 06/05/2011 17:51, Stefan Behnel wrote:
Mark Shannon, 06.05.2011 18:33:
skip@pobox.com wrote:
Antoine> Since we're sharing links, here's Matt Mackall's take: Antoine> http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
> From that note: 1: You can't have meaningful destructors, because when destruction happens is undefined. And going-out-of-scope destructors are extremely useful. Python is already a rather broken in this regard, so feel free to ignore this point.
Given the presence of cyclic data I don't see how reference counting or garbage collection win. Ignoring the fact that in a pure reference counted system you won't even consider cycles for reclmation, would both RC and GC have to punt because they can't tell which object's destructor to call first? It doesn't matter which is called first. May I quote you on that one the next time my software crashes?
Arbitrarily breaking cycles *could* cause a problem if a destructor attempts to access an already collected object. Not breaking cycles *definitely* leaks memory and definitely doesn't call finalizers. You don't need to break the cycles to call the finalizers. Just call
Michael Foord wrote: them, then collect the whole cycle (assuming it is still unreachable).
The GC will *never* reclaim a reachable object. Objects awaiting finalization are reachable, by definition.
Well it was sloppily worded, so replace it with:
if a finalizer attempts to access an already finalized object.
A finalized object will still be a valid object. Python code cannot make an object unsafe. Obviously C code can make it unsafe, but that's true of C code anywhere. For example, a file object will close itself during finalization, but its still a valid object, just a closed file rather than an open one.
Michael
Michael
It may not make a difference for the runtime, but the difference for user software may be "dead" or "alive".
Stefan
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
Mark Shannon wrote:
For example, a file object will close itself during finalization, but its still a valid object, just a closed file rather than an open one.
It might be valid in the sense that you won't get a segfault. But the point is that the destructors of some objects may be relying on other objects still being in a certain state, e.g. a file still being open. One would have to adopt a highly defensive coding style in destructors, verging on paranoia, to be sure that one's destructor code was completely immune to this kind of problem. All of this worry goes away if the destructor is not a method of the object being destroyed, but something external that runs *after* the object has disappeared. -- Greg
participants (2)
-
Greg Ewing -
Mark Shannon