Z
Zed A. Shaw
So I've been doing C extensions for a while now, and there's always been
some nagging questions in my mind about how C extensions mesh with the
GC in Ruby. I've either seen conflicting documentation or no
documentation on certain subjects. I'd like to get some definitive
answers to the following myths or questions.
1. Not providing a mark function to Data_Make_Object or
Data_Wrap_Object means your DATA_PTR memory is not garbage collected.
True or false? My tests say false, but I'm not sure.
2. Using rb_gc_register/rb_gc_unregister is expensive because they are
put into a linked list. True or false?
3. Is there a way to map from my DATA_PTR to the object it is connected
with? Seems like the wisdom is you need your own internal look-up for
this.
4. Can I set a bunch of VALUE variables based on rb_intern("blah") once
during Init(), or do I have to constantly call rb_intern to prevent my
"blah" internal from moving on me? In otherwords, do the interns move
around after they are created?
5. Many C libraries (like libevent) allocate their own memory for
structures and initialize in one shot, but the Data_Wrap_Object macros
and other functions seem to require pre-existing memory. This leads to
a contradiction where I must allocate the libevent structure in my
_alloc method, but initialize it in my _initialize method which I can't
do since allocation and initialization are done in one call. Is there a
way to create, initialize, and attach C library structures inside the
_initialize method only?
6. Is there a way to "protect" ruby objects from moving, collection, or
other "evil" workings while they are needed inside a C extension? My
concrete example is when a handler object is registered inside the
libevent dispatch loop. I want libevent to tell the GC to go to hell
and libevent keeps the object until it is done. Right now I just have
to tell the users to keep their handler objects around, which leads to
all sorts of nastiness.
I think that will do for now. If anyone can give some good feedback on
this then I'll be a very happy camper.
Zed A. Shaw
http://www.zedshaw.com/
some nagging questions in my mind about how C extensions mesh with the
GC in Ruby. I've either seen conflicting documentation or no
documentation on certain subjects. I'd like to get some definitive
answers to the following myths or questions.
1. Not providing a mark function to Data_Make_Object or
Data_Wrap_Object means your DATA_PTR memory is not garbage collected.
True or false? My tests say false, but I'm not sure.
2. Using rb_gc_register/rb_gc_unregister is expensive because they are
put into a linked list. True or false?
3. Is there a way to map from my DATA_PTR to the object it is connected
with? Seems like the wisdom is you need your own internal look-up for
this.
4. Can I set a bunch of VALUE variables based on rb_intern("blah") once
during Init(), or do I have to constantly call rb_intern to prevent my
"blah" internal from moving on me? In otherwords, do the interns move
around after they are created?
5. Many C libraries (like libevent) allocate their own memory for
structures and initialize in one shot, but the Data_Wrap_Object macros
and other functions seem to require pre-existing memory. This leads to
a contradiction where I must allocate the libevent structure in my
_alloc method, but initialize it in my _initialize method which I can't
do since allocation and initialization are done in one call. Is there a
way to create, initialize, and attach C library structures inside the
_initialize method only?
6. Is there a way to "protect" ruby objects from moving, collection, or
other "evil" workings while they are needed inside a C extension? My
concrete example is when a handler object is registered inside the
libevent dispatch loop. I want libevent to tell the GC to go to hell
and libevent keeps the object until it is done. Right now I just have
to tell the users to keep their handler objects around, which leads to
all sorts of nastiness.
I think that will do for now. If anyone can give some good feedback on
this then I'll be a very happy camper.
Zed A. Shaw
http://www.zedshaw.com/