Here's Dino Viehland's response regarding the CERs: ~~~~~~~~
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 ~~~~~~~~~ -Charles On Mon, Oct 4, 2010 at 12:11 AM, Charles Strahan < charles.c.stra...@gmail.com> wrote: > I've decided to not be lazy and do a little spelunking into CER's - it's > rather interesting stuff. I found a pretty good article here: > http://msdn.microsoft.com/en-us/magazine/cc163716.aspx > > In laymen's terms, it looks like CER's provide reliability where > asynchronous exceptions may be thrown: OutOfMemoryException, > StackOverflowException, and ThreadAbortException. In the case of > MemoryHolder, this is important because such exceptions could preempt the > storage of IntPtrs corresponding to allocated memory and/or the deallocation > of memory within finalizers - both resulting in memory leaks. As I imagined, > this will be something we'll want to incorporate in our FFI impl. > > <http://msdn.microsoft.com/en-us/magazine/cc163716.aspx>-Charles > > > On Sun, Oct 3, 2010 at 11:51 PM, Ryan Riley > <ryan.ri...@panesofglass.org>wrote: > >> I've not heard of any of those. I started looking at ctypes but never got >> far. >> >> Sent from my iPhone >> >> On Oct 3, 2010, at 9:27 PM, Charles Strahan <charles.c.stra...@gmail.com> >> wrote: >> >> I'm also taking a look at IronPython's CTypes implementation, under Tomas' >> advice. I've noticed that their >> MemoryHolder<http://github.com/ironruby/ironruby/blob/master/Languages/IronPython/IronPython.Modules/_ctypes/MemoryHolder.cs>class >> derives from >> CriticalFinalizerObject<http://msdn.microsoft.com/en-us/library/system.runtime.constrainedexecution.criticalfinalizerobject.aspx>, >> which led me to the discovery of Constrained Execution >> Regions<http://msdn.microsoft.com/en-us/library/ms228973.aspx> >> . >> >> I sent an inquiry to the IronPython mailing >> list<http://lists.ironpython.com/pipermail/users-ironpython.com/2010-October/013757.html>regarding >> the use CFO, and about CER in general, as I haven't had any >> exposure to either, and the MSDN docs are a little daunting. If anyone here >> would like to give an explanation of either one, that would be awesome. >> >> Any experience with either of those, Ryan? >> >> -Charles >> >> >> On Sun, Oct 3, 2010 at 10:39 PM, Ryan Riley <<ryan.ri...@panesofglass.org> >> ryan.ri...@panesofglass.org> wrote: >> >>> Sounds good to me! >>> >>> Sent from my iPhone >>> >>> On Oct 3, 2010, at 8:04 PM, Charles Strahan <<charles.c.stra...@gmail.com> >>> charles.c.stra...@gmail.com> wrote: >>> >>> Ryan, >>> >>> Sorry for the long delay - I meant to give it some thought before I got >>> back to you... and know it's been quite some time. >>> >>> I think it would be a good idea to replicate JFFI, using P/Invoke >>> directly, if possible (as opposed to P/Invoking >>> libffi<http://www.cygwin.org/libffi/>). >>> That would give us a good separation of concerns and a reusable library, and >>> possibly an easy way to port any Java/JRuby code that uses JFFI to C#/.NET >>> too. >>> >>> I'm about to set up an NFFI repo at >>> <http://github.com/cstrahan/nffi><http://github.com/cstrahan/nffi> >>> http://github.com/cstrahan/nffi. - I suppose you could fork it and send >>> me pull requests (unless you have a better workflow in mind - >>> I'm definitely not a git guru). I've been learning C/C++ the last couple >>> months, so I should be able to write simple DLL to run our tests against. I >>> think I'll take a TDD approach to driving out the C# lib. Once we have NFFI >>> working, it should be relatively straightforward to expose that to the >>> IronRuby runtime. I'll try to get something pushed out to my repo by the end >>> of tomorrow - I'll keep you in the loop. >>> >>> That's what I have in mind, but I'm open to suggestions. >>> >>> -Charles >>> >>> >>> >>> On Sat, Aug 21, 2010 at 9:23 PM, Ryan Riley >>> <<ryan.ri...@panesofglass.org><ryan.ri...@panesofglass.org> >>> ryan.ri...@panesofglass.org> wrote: >>> >>>> Charles, I'm happy to work with you to get this done. I'm getting close >>>> to finishing some projects and will have more time to work on it in a few >>>> weeks. I will send the info I got from the mono-devel list. Where/how do >>>> you >>>> want to start? >>>> >>>> Ryan >>>> >>>> Sent from my iPhone >>>> >>>> On Aug 20, 2010, at 1:49 PM, Charles Strahan >>>> <<charles.c.stra...@gmail.com><charles.c.stra...@gmail.com> >>>> charles.c.stra...@gmail.com> wrote: >>>> >>>> Ryan, >>>> >>>> I'm right there with you, only I looked at JFFI for inspiration (didn't >>>> know mono had anything - could you share more about that?). In fact, In my >>>> infinite laziness, I posted a job for a couple hundred bucks on >>>> Rent-A-Coder, hoping someone could essentially port JFFI to C#, so I could >>>> focus on writing the actually IronRuby library... but nothing came of that. >>>> >>>> I'm tempted to suck it up and start coding this myself. Would you be >>>> interested in working together? I figured I'd take the approach of >>>> essentially writing "NFFI", and then write an IronRuby lib around that. >>>> >>>> -Charles >>>> >>>> >>>> On Fri, Aug 20, 2010 at 2:33 PM, Ryan Riley >>>> <<ryan.ri...@panesofglass.org><ryan.ri...@panesofglass.org><ryan.ri...@panesofglass.org> >>>> ryan.ri...@panesofglass.org> wrote: >>>> >>>>> I know that we've discussed this in the past, but I'm interested in >>>>> doing it for two reasons: >>>>> 1. We use mono with a bridge to ObjectiveC and Cocoa, and we'd like to >>>>> investigate libffi via mono as a potential replacement for our current >>>>> bridge. >>>>> 2. I'm interested just for the sake of learning more about FFI. >>>>> >>>>> Mono appears to have had a libffi implementation that was later >>>>> removed, so I think I have a place to start. However, I'm not sure that's >>>>> the right starting point. Does anyone have a suggestion for how to get >>>>> started? I've been taking a look at libffi and DllImport, but I'm not sure >>>>> if those are the right directions, something else, or what. >>>>> >>>>> Thanks, >>>>> >>>>> Ryan Riley >>>>> >>>>> Email: <ryan.ri...@panesofglass.org> >>>>> <ryan.ri...@panesofglass.org><ryan.ri...@panesofglass.org> >>>>> ryan.ri...@panesofglass.org >>>>> LinkedIn: >>>>> <http://www.linkedin.com/in/ryanriley><http://www.linkedin.com/in/ryanriley><http://www.linkedin.com/in/ryanriley> >>>>> http://www.linkedin.com/in/ryanriley >>>>> Twitter: @panesofglass >>>>> Blog: <http://wizardsofsmart.net/> >>>>> <http://wizardsofsmart.net/><http://wizardsofsmart.net/> >>>>> http://wizardsofsmart.net/ >>>>> Website: <http://panesofglass.org/> >>>>> <http://panesofglass.org/><http://panesofglass.org/> >>>>> http://panesofglass.org/ >>>>> >>>>> _______________________________________________ >>>>> Ironruby-core mailing list >>>>> <Ironruby-core@rubyforge.org> >>>>> <Ironruby-core@rubyforge.org><Ironruby-core@rubyforge.org> >>>>> Ironruby-core@rubyforge.org >>>>> >>>>> <http://rubyforge.org/mailman/listinfo/ironruby-core><http://rubyforge.org/mailman/listinfo/ironruby-core><http://rubyforge.org/mailman/listinfo/ironruby-core> >>>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>>> >>>>> >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> <Ironruby-core@rubyforge.org> <Ironruby-core@rubyforge.org> >>>> Ironruby-core@rubyforge.org >>>> >>>> <http://rubyforge.org/mailman/listinfo/ironruby-core><http://rubyforge.org/mailman/listinfo/ironruby-core> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>>> >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> <Ironruby-core@rubyforge.org> <Ironruby-core@rubyforge.org> >>>> Ironruby-core@rubyforge.org >>>> >>>> <http://rubyforge.org/mailman/listinfo/ironruby-core><http://rubyforge.org/mailman/listinfo/ironruby-core> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> <Ironruby-core@rubyforge.org>Ironruby-core@rubyforge.org >>> <http://rubyforge.org/mailman/listinfo/ironruby-core> >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> <Ironruby-core@rubyforge.org>Ironruby-core@rubyforge.org >>> <http://rubyforge.org/mailman/listinfo/ironruby-core> >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core@rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core@rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
