qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darryl L. Pierce" <dpie...@redhat.com>
Subject Re: Proton and Ruby object references...
Date Mon, 09 Mar 2015 13:13:03 GMT
On Fri, Mar 06, 2015 at 04:41:34PM -0500, Darryl L. Pierce wrote:
> Revisiting this topic given newly discovered issues:

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.


Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.

View raw message