[IronPython] Question about CriticalFinalizerObject usage.

[Charles Strahan]

Awesome - that makes sense! That's something I'll definitely want to
consider for my FFI implementation. As you mentioned, it won't be a problem
in most cases, but for those that do wish to use my FFI implementation
*and*require reliable resource management, it's something I'll need to
account
for sooner or later.

Thanks Dino,
-Charles

On Mon, Oct 4, 2010 at 12:48 AM, Dino Viehland <dinov at microsoft.com> wrote:

>  Objects which inherit from CriticalFinalizerObject basically have their
> finalize method turned into a CER.  The finalizer method is also JITed
> before any instances are created so the finalizer is guaranteed to be
> runnable.
>
>
>
> In generally CERs are all about ensuring that the VM won’t cause any
> unexpected failure points in your code.  These can be introduced because the
> VM does something lazily (including JITing methods) and doing the work might
> fail due to insufficient resources.  Or it can also be due to thread abort.
> Because these objects are responsible for freeing up resources we don’t want
> any unexpected failures to be injected otherwise the resources would leak.
>
>
>
> So for example MemoryHolder also has a CER in the constructor – this
> ensures that we don’t take a ThreadAbort between the CallocCall, storing the
> value in _data, or assigning to _ownsData.  This will all complete or not
> complete so that our state is consistent when the finalizer is run.  It also
> makes sure that any work the CLR needs to perform to call
> NativeFunctions.Calloc is all performed before we enter the CER so that we
> don’t get an out of memory exception while calling or returning from it.
>
>
>
> For most environments it’s not super important that this is gotten right –
> but if you run in a process which needs long uptime, is resource
> constrained, and/or uses thread abort a lot (SQL server being an example of
> all 3) it’s important that this is correct.  I happened to work on this
> feature when I was on the CLR team so it came rather naturally to me to get
> it right J
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Charles Strahan
> *Sent:* Sunday, October 03, 2010 9:11 PM
> *To:* users at lists.ironpython.com
> *Subject:* [IronPython] Question about CriticalFinalizerObject usage.
>
>
>
> Hello,
>
>
>
> I'm about to begin work on implementing the FFI gem<http://rubygems.org/gems/ffi>for IronRuby, and I was referred to IronPython's CTypes for inspiration. I
> noticed that the MemoryHolder inherits from CriticalFinalizerObject, and I
> was curious why that is. I'm actually not familiar with Constrained
> Execution Regions in general, so a quick high level description would be
> awesome. I've briefly looked at the following MSDN docs, but they're a
> little too fine-grained for me to follow:
>
>
>
>  CriticalFinalizerObject Class:
> http://msdn.microsoft.com/en-us/library/system.runtime.constrainedexecution.criticalfinalizerobject.aspx
>
> System.Runtime.ConstrainedExecution Namespace:
> http://msdn.microsoft.com/en-us/library/system.runtime.constrainedexecution.aspx
>
> Constrained Execution Regions:
> http://msdn.microsoft.com/en-us/library/ms228973.aspx
>
> Reliability Best Practices:
> http://msdn.microsoft.com/en-us/library/ms228970.aspx
>
>
>
> Any help in understanding the purpose of CriticalFinalizerObject and why it
> is used as the base class for MemoryHolder would be greatly appreciated.
>
>
>
> Thanks!
>
> -Charles
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20101004/6080d3a2/attachment.html>