@Charles Have you made any progress here? If so, what's your repo? I'm looking into this again this morning.
Cheers, Ryan Riley Email: ryan.ri...@panesofglass.org LinkedIn: http://www.linkedin.com/in/ryanriley Twitter: @panesofglass Blog: http://wizardsofsmart.net/ Website: http://panesofglass.org/ On Sun, Oct 3, 2010 at 11:47 PM, Charles Strahan < charles.c.stra...@gmail.com> wrote: > 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 > >
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
