On Dec 21, 2009, at 1:21 PM, Jon 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?

Yes, typo. I meant that the pointed to native heap memory is not acted upon.

> 
> 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?

Not automatically, no. The user is responsible for releasing it back. Because every C library does this different (use free(), call a specific cleanup function), we can never do anything without more information or explicit action.

> 
> 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?

Yes, thats a big problem. You need to be cleaning up those resources manually based on the rules of whatever C code you're interacting with.

 - Evan

> 
> Jon
>