From: "Zed A. Shaw" Date: 2005-07-08T09:43:19+09:00 Subject: Questions about GC, memory management and C extensions 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/