[Ironruby-core] IronRuby FFI

Ryan Riley ryan.riley at panesofglass.org
Sat Oct 23 13:06:01 EDT 2010


@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.riley at 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.strahan at 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.strahan at 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.riley at 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.strahan at 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.riley at panesofglass.org>
>>> ryan.riley at panesofglass.org> wrote:
>>>
>>>> Sounds good to me!
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Oct 3, 2010, at 8:04 PM, Charles Strahan <<charles.c.strahan at gmail.com>
>>>> charles.c.strahan at 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.riley at panesofglass.org><ryan.riley at panesofglass.org>
>>>> ryan.riley at 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.strahan at gmail.com><charles.c.strahan at gmail.com>
>>>>> charles.c.strahan at 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.riley at panesofglass.org><ryan.riley at panesofglass.org><ryan.riley at panesofglass.org>
>>>>> ryan.riley at 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.riley at panesofglass.org> <ryan.riley at panesofglass.org><ryan.riley at panesofglass.org>
>>>>>> ryan.riley at 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 at rubyforge.org> <Ironruby-core at rubyforge.org><Ironruby-core at rubyforge.org>
>>>>>> Ironruby-core at 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 at rubyforge.org> <Ironruby-core at rubyforge.org>
>>>>> Ironruby-core at 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 at rubyforge.org> <Ironruby-core at rubyforge.org>
>>>>> Ironruby-core at 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 at rubyforge.org>Ironruby-core at rubyforge.org
>>>>  <http://rubyforge.org/mailman/listinfo/ironruby-core>
>>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>>
>>>>
>>>> _______________________________________________
>>>> Ironruby-core mailing list
>>>>  <Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org
>>>>  <http://rubyforge.org/mailman/listinfo/ironruby-core>
>>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>>
>>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>>>
>>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101023/029e5482/attachment-0001.html>


More information about the Ironruby-core mailing list