Two ingredients case a memory leak in ANY python program: __del__ and
circular references. You need them both.
In the case of web2py "exec code in {}" creates the circular reference
for objects defined in the code. This does not mean web2py has a
memory leak. In fact, as pointed out, no web2py class has a __del__
therefore the second ingredient necessary for the leak is missing. The
leak happens if and only if the developers define a class in model or
controller that contains a __del__ method. This is the test case that
mitsuhiko engineered for us.
BOTTOM LINE: do not create classes in model/controller that have a
__del__. Not that anybody is doing this to my knowledge.
I am looking if it is possible to create code to detect these circular
references and break them anyway. Not a priority for me since,
practically, this is not an issue. Yet, theoretically, I find it
interesting.
I really wish the move from python 2.x to 3.x had addressed this issue
by switching from reference counting to garbage collecting (like Java,
Ruby, .Net and Erlang). It would have made the move to 3.x very
compelling.
Massimo
On Jan 8, 12:00 pm, VP <vtp2...@gmail.com> wrote:
> Without actually trying it, but it still seems the cause for memory
> leak of (A) and (B) is different. (B) is a case of circular reference,
> and as such reference counting garbage collection (cpython) will fail
> to work properly.
>
> But (A), which is the leak in web2py, does not seem to related to
> circular reference.
>
> (A)
>
> >>code="""
> >>class Foo(object):
> >> def __del__(self):
> >> pass
> >>foo = Foo()
> >>"""
> >>while True: exec code in {}
>
> >>causes a memory leak. Web2py does this.
>
> (B)
>
>
>
>
>
>
>
> >>class Foo(object):
> >> def __del__(self):
> >> pass
> >>while True:
> >> foo = Foo()
> >> foo.x = foo
