[IronPython] Question about CriticalFinalizerObject usage.

[Dino Viehland]

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 :)

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20101004/28d149e2/attachment.html>