[IronPython] Thread local storage in IronPython 2.6

[Michael Foord]

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
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog