From: "evanwebb@..." <evanwebb@...>
Date: 2005-07-08T10:55:46+09:00
Subject: Re: Questions about GC, memory management and C extensions

A few answers:

1. GC does nothing with the DATA_PTR. The mark function provides the
owner of the Data object (you) the ability to do additional marking of
objects during the mark phase. The primo example of this is that the
struct you've stuffed into the DATA_PTR of your object contains a VALUE
element that is a ruby object (perhaps, say, a handler object). You
want to make sure that the GC knows that this object is still live, so
you'd call gc_mark(my_struct->element) within your mark function. This
also anwsers #6, how to protect objects from the GC. Remember, the GC
is trying to find all live objects, so if you've got a live object that
the GC can't see any other way, you need to mark it.

2. Yes, they go into a linked list. They are as expensive as a linked
list.

3. No, there is no mechanism to map something stuffed into a DATA_PTR
back to the object it was stuffed into. The reason is that ruby doesnt
want to know what you put in a DATA_PTR, thats your business, not it's.
You can easily (and nicely) have many objects that have the same struct
stuffed into their DATA_PTR.

4. Yes, you can call rb_intern() within an Init safely. The behavior of
rb_intern is as they say, deterministic during all phases of runtime.

rb_intern("blah") == rb_intern("blah") is always true.

5. A common way to tackle this problem is to define the method "new" on
your class, where that function creates and initializes a new instance,
then returns it. I kind of remember matz and friends saying that this
was a bad practice, but I don't know what the other method is (other
than what you've already got).

6. See #1

Hope this helps!