[docs] [issue17468] Generator memory leak

[Anssi Kääriäinen]

Anssi Kääriäinen added the comment:

I was imagining that the collection should happen in two passes. First check for tp_dels and call them if safe (single tp_del in cycle allowed). Then free the memory. The first pass is already there, it just doesn't collect callable tp_dels.

If it would be possible to turn an object into inaccessible state after tp_del was called it would be possible to call multiple tp_dels in a cycle. If the del tries to use already deleted object you will get some sort of runtime exception indicating access of already collected object (another option is to allow access to object which has already had __del__ called, but that seems problematic).

Now, both of the above are likely way more complicated to implement than what I imagine. I have very little knowledge of the technical details involved.

If I understand correctly your idea was to do something similar to above, but only for generators.

The current situation is somewhat ugly. First, I can imagine people wishing to do try-finally or something "with self.lock:" in a generator. These will leak in circular reference cases. The generator case is surprising, so surprising that even experienced programmers will do such mistakes (see the django ticket for one example). Second, from application programmers perspective the fact that __del__ wasn't called is usually similar to having a silent failure in their code - for example this can result in leaking database connections or other resources, not to mention possible problems if one has a "with self.lock:" block in a generator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17468>
_______________________________________