Thomas wrote:

>>If the VALUE (which is the C data type that points to a Ruby object) is 
>>on the stack, so long as it doesn't go out of scope, Ruby will not 
>>collect the object.  This means that, for objects you create for use 
>>during a function call, you don't need to do ANYTHING; Ruby protects it 
>>until your function returns.
> 
> 
> My reference will be stored on the managed heap in .net and will not
> be on the stack.
> 
> 
>>Another way to do it is to create a C VALUE variable globally or as part 
>>of a class.  You can call rb_gc_register_address to register the memory 
>>space holding the VALUE.  So long as your variable exists, Ruby protects 
>>the object it points to.  When you are done with the object, call 
>>rb_gc_unregister_address.
> 
> 
> Well this interests me. You say I need to allocate it globally? Can I
> store it on the (unmanaged) heap?
> 
> I dug out the source for rb_register_address 
> 
> void
> rb_gc_register_address(addr)
>     VALUE *addr;
> {
>     struct gc_list *tmp;
> 
>     tmp = ALLOC(struct gc_list);
>     tmp->next = global_List;
>     tmp->varptr = addr;
>     global_List = tmp;
> }
> 
> And it seems it adds the VALUE *addr to a linked list, which I guess
> will then be protected from gc'ing. It seems allocating the VALUE on
> the heap should be perfectly safe. Is it?
> 
> This would work for me, as I can keep a reference to the unmanaged
> heap object from managed space. and clean it up when the managed
> reference goes away.

That should work just fine; with register_address, it's only important 
that the memory space for the VALUE doesn't go away, so any memory heap 
should do (assuming .net doesn't do some sort of weird virtual memory 
thing where the memory space you allocate can move around).

	Sean O'Dell