From: Tilman Sauerbeck <tilman@...>
Date: 2004-07-31T03:21:19+09:00
Subject: Re: C ext: GC claiming objects early

ts <decoux@moulon.inra.fr> [2004-07-30 17:20]:
> >>>>> "T" == Tilman Sauerbeck <tilman@code-monkey.de> writes:
> 
> T> 	rb_obj_call_init (rbres->self, 0, NULL);
> 
>  this is, no ?
> 
>         rb_obj_call_init(self, 0, NULL);

Yes, that's it. rbres->self came from an older version I experimented
with.

> T> static VALUE c_notifier_set (VALUE self)
> 
>  Well, you attach a notifier to an object but with the construct
> 
>    o.some_meth.notifier do |r|
>       do_stuff_with(r)
>    end
> 
>  this object is never stored in a variable, this is why ruby remove it
> 
>  Normally you must write it
> 
>    res = o.some_method
>    res.notifier do |r|
>       do_stuff_with(r)
>    end
> 
>  and it will work, until ruby call the GC for `res'
> 
>  If you want to make it work like it is actually, you must store the result
>  of `o.some_method' in an Array defined in `o' when #notifier is called,
>  and mark this array. It will be marked when ruby will mark `o'

Yeah. Although if I make the parent object (the XmmsClient, 'o') know
about (and mark) the Result objects, I've got a circular reference,
since the result objects mark their parent, which is 'o'.
I do it that way to make sure all result objects are claimed before the
XmmsClient object.

>  Now the problem is here
> 
> T> I _do_ want the GC to claim the object eventually, but not if the
> T> callback might still be called.
> 
>  How do you know that the callback might still be called ?

No idea :)
I hoped Ruby would make the block object mark the result object, since
it allocated the block.

This would actually solve all of my problems at this point, I think.

-- 
Regards,
Tilman