From: Sean O'Dell <sean@...>
Date: 2004-07-30T23:27:02+09:00
Subject: Re: C ext: GC claiming objects early

On Friday 30 July 2004 06:56, Tilman Sauerbeck wrote:
> Sean O'Dell <sean@celsoft.com> [2004-07-30 15:42]:
> > On Thursday 29 July 2004 13:11, Tilman Sauerbeck wrote:
> > > I know I can work around this by using rb_global_variable() to tell the
> > > GC not to claim the object, but this kinda sucks since the object will
> > > never be freed :(
> > >
> > > So, my question is: how do I prevent the Result object from being
> > > claimed by the GC without using rb_global_variable's?
> >
> > If this object is a VALUE variable in your C code, you should declare it
> > this way:
> >
> >     volatile VALUE result = Qnil;
> >
> > Adding volatile allows the GC to see the object on the C stack.  This
> > means that so long as your C code holds it in that variable, it will
> > never go away.
>
> Okay, but that wouldn't really be different from using
> rb_global_variable() and rb_gc_unregister_address(), right?

It's completely different; it's for VALUEs on the stack.  By declaring it 
volatile, you force the VALUE on the C stack, where the GC can see it.  The 
variable can be local to a C function and if the GC is called, it will see it 
and not collect it.

> I just noticed my last question was badly worded :/
> I _do_ want the GC to claim the object eventually, but not if the
> callback might still be called.

I haven't seen your C code, so I'm not sure what is happening, but if you are 
maintaining the VALUE as a global and returning control to Ruby, then trying 
to use the global in a callback, you should register the VALUE with 
rb_global_variable or rb_gc_register_address to keep the GC from collecting 
it.

	Sean O'Dell