qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aconway <acon...@redhat.com>
Subject Simplifying proton C memory management [was Re: [qpid-proton] Proton C++ binding Object Memory Management changes (#4)]
Date Fri, 20 Nov 2015 15:19:58 GMT
[Continuing a discussion from 
but it has become a discussion of the C library which is separate from
the original C++ issue so new thread]

On Thu, 2015-11-19 at 14:28 -0800, Andrew Stitcher wrote:
> So actually we should be moving to completely remove all the *_free()
> functions then - or at least the ones that pertain to everything that
> is an "object" in proton-c.
> —
> Reply to this email directly or view it on GitHub.

In the C API, *for objects created by the user*, I think we should keep
a normal C API that does not require the use of refcounts:

  foo_t* x= pn_foo(); pn_foo_free(x);

Note only a few objects can be created by the user. With the reactor
only pn_reactor_t and pn_data_t. With the engine also pn_connection_t,
pn_transport_t and pn_collector_t.

Most objects (link, session, disposition etc.) are only created by the
library. The user can incref/decref to extend their lifetime but should
never free them.

So I would be in favour of dropping pn_*_free for all objects that
cannot be created by the user, and for others making free an alias for

    void pn_foo_free(pn_foo_t* x) { pn_decref(x); }

There is a lot of logic in proton to distinguish between calls to
"_free" and "_decref" which IMO is a bad idea. Normal alloc/release
memory management is a trivial special case of reference counting where
the reference count only ever gets to 1. So other than providing the
expected pn_*_free() aliases for decref, I don't see why there would be
any _free logic at all for reference counted objects.

Is this simply left-over from the transition from a non-refcounted
codebase that can be cleaned up or is there more to  it?

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message