Dino Viehland wrote:
*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.
Ideally we wouldn't leak memory with frames on though! :) In theory
when a new thread gets created we will replace the old threads memory and
everything can be reclaimed. But I could change this so that we use a
normal thread static which will get cleaned up eagerly (it'll have some
small performance impact when frames are enabled though).
Well, yes leaking memory when frames are on would definitely be a
problem. We tried but failed to create a minimal repro.
The recompiling issue is slightly concerning as well. Is it the case
that if we compile all our libraries with Pyc with frames off then we
can't use them from an engine with the tracing / frames / debugging
options on (taking advantage of frames and debugging support)?
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
