On Thu, May 7, 2015 at 9:41 AM, Darryl L. Pierce <dpie...@redhat.com> wrote:
> I've been working on this codebase since the beginning of the year. The
> two branches [1, 2] in my git repo represent the low-level engine APIs
> and the higher-level reactive APIs, respectively.
> I'm still working through the set of example apps for the reactive APIs,
> but at this point I feel this is close enough that I want to start
> getting feedback from people.
> == Memory Concerns
> Of particular important is memory management: the Proton libraries use
> reference counting to manage object lifespans, while Ruby uses mark and
> sweep operations for garbage collection. So ensuring that pure Ruby
> objects aren't reaped when they've only known to the Proton libraries,
> in the case of event handlers specifically, has been a challenge and one
> that's sure to have some cases that need fixing.
> The first model explored was to attachment the Ruby wrapper objects to
> the Swig-generated wrappers for the underlying C structs in Proton.
> Which worked at first, but turned out to be not useful. The reason being
> that the Swig bindings were themselves being reaped when they went out
> of scope; i.e., Swig doesn't maintain them by providing a mark operation
> until disposal of the underlying C structs. So this path, while
> initially promising, was discarded.
> The current model uses a hash table that is attached to the Qpid::Proton
> module. When objects are stored for use by the C libraries, they are
> tucked away in this hash table with a unique key generated based on
> memory addresses. A copy of that key, as a char*, is given to Proton to
> use later when the object is being retrieved.
> To help with this, two additional callback APIs were added to the Proton
> libraries: pn_record_set_callback and pn_record_has_callback. These two
> functions work to help register a method to be called whenever a record
> is deleted to enable memory management. This way the above-mentioned key
> can be properly deleted, and the value stored in the hash table
I would need to see the code in detail, but I suspect you don't need to add
a pn_record_set_callback/get_callback to achieve roughly the functionality.
I *think* you could simply define a pn_class_t that is a reference counted
holder of your key. You could then put your callback logic in the finalizer
for that class, and when proton's reference counting triggers the
finalizer, it will run the callback logic at the appropriate time.
> The reference counting aspect of the Proton libraries is a concern as
> well. The code currently increments and decrements references in the
> same places as the Python code, but there are likely more places where
> such reference accounting need to be added.
>  http://github.com/mcpierce/Proton/tree/PROTON-799-Ruby-engine-apis
>  http://github.com/mcpierce/Proton/tree/PROTON-781-reactive-ruby-apis
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.