Dino Viehland wrote:
Michael wrote:
We're working on the port of Resolver One to IronPython 2.6. We're
finding that in quite a few of our tests our documents are now not being
garbage collected, which would be a major memory leak in Resolver One if
left unaddressed.
As far as we can *tell* what is keeping the documents alive is a
PythonFunctionStack (?) in thread local storage, put there by IronPython
itself. This doesn't happen with IronPython 2. Does this ring a bell as
a change in IronPython 2.6?
What's the threading story like in your tests? Is it just one thread or
are you repeatedly creating new threads?
Another way of looking at this is the ThreadLocal object has a _stores
array. What indexes in that array are keeping the objects alive?
It is a multithreading situation (each document has its own
recalculation thread which is destroyed when the document is no longer
needed).
*However*, we discovered that we inadvertently had options["Frames"] =
true; in the code that creates the main engine. Switching that off (and
then having to recompile all our Python code) solved the problem.
It may indicate that if we want to turn frames on in individual engines
(each recalculation thread has its own Python engine) then we may have a
problem - but it is no longer blocking us. Sorry for the noise.
All the best,
Michael
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
