[Ironpython-users] LightweightScopes and scopes in general
igor.brejc at gmail.com
Sat Feb 11 16:11:03 CET 2012
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?
I'm wondering how other people who use IronPython as an embedded scripting
engine deal with these issues (if at all).
On Fri, Feb 10, 2012 at 10:40 PM, Dino Viehland <dinov at microsoft.com> wrote:
> 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.****
> ** **
> *From:* Igor Brejc [mailto:igor.brejc at gmail.com]
> *Sent:* Friday, February 10, 2012 10:51 AM
> *To:* Dino Viehland
> *Cc:* Jeff Hardy; Ironpython-users at python.org
> *Subject:* Re: [Ironpython-users] LightweightScopes and scopes in general*
> ** **
> ** **
> On Fri, Feb 10, 2012 at 7:46 PM, Dino Viehland <dinov at microsoft.com>
> Jeff wrote:
> > I'm taking a stab off the top of my head based on my limited knowledge
> of the
> > internals, but I do know that debug code is not collectable.
> > It's possible that the code itself may be holding references that keep
> > alive longer than expected.
> > I believe if you run the code in a separate AppDomain you can unload the
> > AppDomain and the code will be collected, which should take everything
> > with it.
> > >
> > > I've also tried running in the release mode and turning on the
> > > options["LightweightScopes"] = true mode, which seems to help. But I
> > > cannot find any information about what this option actually does and
> > > what happens with the scope variables in general. Any info would be
> > appreciated.
> > That one I'll have to leave to Dino.****
> The difference between the different types of scopes just comes down to how
> we hold onto global variable and call site objects.
> The most efficient way to hold onto these is to use CLR static fields to
> store the
> global variables. That allows the CLR to generate a direct access to the
> field and
> we can quickly access the global variables. But it comes at the cost of
> not being
> able to recover the static fields and leaking the values that are stored
> in there.
> The light weight scopes store the variables in a field or an array instead
> of storing
> them in static fields. To do that we need to pass in the field or close
> over it and then
> on each access we need to do the field or array access (and if it's an
> array access, it
> needs to be bounds checked). But the end result is that the only thing
> which is keeping
> the global variable / call site objects alive are the delegate which
> implements the
> ScriptCode. Once the ScriptCode goes away all of those call sites and
> objects can be collected.
> So lightweight scopes come at a performance cost, but they are more
> Where you're actually re-compiling code regularly.
> ** **
> Thanks for that explanation, Dino.****
> ** **
> 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)? ****
> ** **
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ironpython-users