[Continuing a discussion from https://github.com/astitcher/qpid-proton/pull/4#issuecomment-158207053 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 decref: 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-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org