On Mon, Dec 21, 2009 at 3:21 PM, Jon <jon.forums@gmail.com> wrote:

>> I'll address the biggest hole in this here. FFI::MemoryPointer, FFI::Struct, and FFI::ManagedStruct are all proxy objects. Nothing they reference lives in the ruby heap.

>
> While these proxy objects live in the ruby heap and are subject to the will of the specific ruby impls gc, the real goodies are always in the native heap.  Got it, thanks.
>
>

>> When a ruby GC detects that an FFI::Struct is garbage, the memory that the FFI::Struct references is acted upon at all. This is because FFI::Struct is just a proxy for some unmanaged memory.

>
> You mean the unmanaged mem is *not* acted upon at all (typo) right?
>
> Are you also saying that if the proxy object is ruby GC'd the unmanaged mem is (currently) never freed by any of the impls?
>
> So while we should never see the dangling pointer class of issues, do you see real-world potential for writing ruby ffi code that can easily leak memory?  For example, if I'm creating/destroying FFI::Struct proxies in a callback in some long-lived process, the ruby heap will be cleaned but the underlying unmanaged mem in the native heap would not be?

I have been wondering about the Struct API myself.   It seems like it
should support a simple explicit memory management API ala:

class MyFFIStruct < FFI::Struct ....

MyFFIStruct.new do |struct_instance|
   some_ffi_call struct_instance
   # Do other stuff....
end
# I know the block has disposed of my allocated struct

Even if FFI does reclaim memory on an FFI struct when proxy object
collects this is a complete disaster in a Java VM where it can take
literally forever to GC a Java object (as mentioned
non-deterministic).  An explicit API also encourages people to not
leak by default.  If this is already in the API, then tell me to shut
up :)

BTW- I am writing a windows automation library using JRuby and I am
wonder more about the idiomatic way to manage lifecycles of structs
and pointers.

-Tom

-- 
blog: http://blog.enebo.com       twitter: tom_enebo
mail: tom.enebo@gmail.com