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 <di...@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-boun...@lists.ironpython.com [mailto: > users-boun...@lists.ironpython.com] *On Behalf Of *Charles Strahan > *Sent:* Sunday, October 03, 2010 9:11 PM > *To:* users@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@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
