On Fri, Mar 06, 2015 at 04:41:34PM -0500, Darryl L. Pierce wrote: > Revisiting this topic given newly discovered issues: <snip>
Thinking about this over the weekend, it feels like it would be a huge nightmare to try and put a shim in place to keep a Ruby object held by a C struct from being reaped. Especially given that Swig is recreating Ruby wrappers and losing state information on them. But I had an idea taken from a previous project that feels like it would solve this issue. Instead of having a Proton C struct hold a reference to a Ruby object and dealing with the GC issues, why not instead have that C struct hold a unique string? Within Ruby we can maintain a private (not visible to the application) hashtable that uses that string value as a key to point to a Ruby object that is the true value of interest. To assist this, we would add a function pointer to the record APIs (pn_record_remove) that gets called when a record is deleted. It passes in the void* value for each field in the record, if the function is assigned, and that function can work as a hook to remove the object from the global hash. Why do this instead of having C hold a Ruby object and stuffing the Ruby object into some sort of array? I think it would be a simpler, cleaner operation to have C not know if's holding onto Ruby. So, for example, if something happened to the hash or the object held in the hash, we wouldn't get a segfault to access the value from C: instead, we would have a key with no matching value. Something that would be easier to debug than what could appear to be a random segfault. Thoughts? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
pgpG_tP74PzQd.pgp
Description: PGP signature
