<div>I'm thinking of this scenario: my host application allows users to run their own Py scripts. OK, in the ideal case, their scripts should take care of the disposal of the reserved resources, but a lot of times user will write trail-and-error scripts which will often fail. Is there a mechanism for the host application to somehow track (and possibly dispose) of the stuff that has been allocated in a failed user script? Using SetTrace() or by simply examining the ScriptScope after the script has finished? Or should I simply ignore this?</div>
<div><br></div><div>I'm wondering how other people who use IronPython as an embedded scripting engine deal with these issues (if at all).</div><div><br></div><div>Thanks,</div><div>Igor</div><br><div class="gmail_quote">
On Fri, Feb 10, 2012 at 10:40 PM, Dino Viehland <span dir="ltr"><<a href="mailto:dinov@microsoft.com">dinov@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">We won’t call IDispose on them. Usually they’ll follow the pattern of implementing IDisposable + having a finalizer so they will eventually release their resources.Â
Also they can be used with the “with†statement so that their Dispose methods are eagerly called.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u>Â <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Igor Brejc [mailto:<a href="mailto:igor.brejc@gmail.com" target="_blank">igor.brejc@gmail.com</a>]
<br>
<b>Sent:</b> Friday, February 10, 2012 10:51 AM<br>
<b>To:</b> Dino Viehland<br>
<b>Cc:</b> Jeff Hardy; <a href="mailto:Ironpython-users@python.org" target="_blank">Ironpython-users@python.org</a><br>
<b>Subject:</b> Re: [Ironpython-users] LightweightScopes and scopes in general<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u>Â <u></u></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u>Â <u></u></p>
<div>
<p class="MsoNormal">On Fri, Feb 10, 2012 at 7:46 PM, Dino Viehland <<a href="mailto:dinov@microsoft.com" target="_blank">dinov@microsoft.com</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
Jeff wrote:<br>
> I'm taking a stab off the top of my head based on my limited knowledge of the<br>
> internals, but I do know that debug code is not collectable.<br>
> It's possible that the code itself may be holding references that keep objects<br>
> alive longer than expected.<br>
><br>
> I believe if you run the code in a separate AppDomain you can unload the<br>
> AppDomain and the code will be collected, which should take everything else<br>
> with it.<br>
><br>
> ><br>
> > I've also tried running in the release mode and turning on the<br>
> > options["LightweightScopes"] = true mode, which seems to help. But I<br>
> > cannot find any information about what this option actually does and<br>
> > what happens with the scope variables in general. Any info would be<br>
> appreciated.<br>
><br>
> That one I'll have to leave to Dino.<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">The difference between the different types of scopes just comes down to how<br>
we hold onto global variable and call site objects.<br>
<br>
The most efficient way to hold onto these is to use CLR static fields to store the<br>
global variables. Â That allows the CLR to generate a direct access to the field and<br>
we can quickly access the global variables. Â But it comes at the cost of not being<br>
able to recover the static fields and leaking the values that are stored in there.<br>
<br>
The light weight scopes store the variables in a field or an array instead of storing<br>
them in static fields. Â To do that we need to pass in the field or close over it and then<br>
on each access we need to do the field or array access (and if it's an array access, it<br>
needs to be bounds checked). Â But the end result is that the only thing which is keeping<br>
the global variable / call site objects alive are the delegate which implements the<br>
ScriptCode. Â Once the ScriptCode goes away all of those call sites and PythonGlobal<br>
objects can be collected.<br>
<br>
So lightweight scopes come at a performance cost, but they are more applicable<br>
Where you're actually re-compiling code regularly.<br>
<br>
<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u>Â <u></u></p>
<div>
<p class="MsoNormal">Thanks for that explanation, Dino.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u>Â <u></u></p>
</div>
<div>
<p class="MsoNormal">Another question that pops up: what happens with Disposable objects (like files, GDI+ bitmaps etc.) created within the Py scope (if they are not referenced from the outside)? Â
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u>Â <u></u></p>
</div>
<div>
<p class="MsoNormal">Igor<u></u><u></u></p>
</div>
</div></div></div>
</div>
</div>
</blockquote></div><br>