On Thu, May 07, 2015 at 11:32:33AM -0400, Rafael Schloming wrote:
> On Thu, May 7, 2015 at 10:40 AM, Darryl L. Pierce <[email protected]>
> wrote:
> 
> > On Thu, May 07, 2015 at 09:57:49AM -0400, Rafael Schloming wrote:
> > > On Thu, May 7, 2015 at 9:41 AM, Darryl L. Pierce <[email protected]>
> > wrote:
> > <snip>
> > > > 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
> > > > discarded.
> > >
> > > 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.
> >
> > (edit)
> >
> > As I was writing up a description of the code I realized I have already
> > done what you suggest above WRT the pni_rbhandler_t type. I could use
> > the same logic to create a pni_rbrecord_t type and manage its lifecycle
> > the same way the handler's lifecycles are managed, yeah?
> 
> Yes, I believe so.

Since records are created when a struct if initially created, I'm not
sure how to go about attaching the key to its lifecycle since the
dynamic language isn't explicitly creating the record.

-- 
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/

Attachment: pgpPrDtwTjlAX.pgp
Description: PGP signature

Reply via email to