qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aconway <acon...@redhat.com>
Subject Semantics of proton refcounts [was Re: proton 0.10 blocker]
Date Thu, 16 Jul 2015 13:40:58 GMT
On Wed, 2015-07-15 at 17:30 +0100, Gordon Sim wrote:
> The latest proton code is causing crashes in qpid-cpp tests that use 
> it. 
> I've tracked the problem down to the fix for PROTON-905[1] and 
> proposed 
> an enhancement to that fix, https://reviews.apache.org/r/36509/, 
> which 
> avoids the crash.
> 
> Could someone who understands the logic controlling the lifecycle of 
> pn_session_t and pn_link_t objects in detail review and approve this 
> please?

Can someone who understand the proton use of refcounts please add some
doc comments to explain the semantics? Apologies if this is already
there and I missed it, tell me to RTFM.

For comparison here is what "refcount" traditionally means ("tradition"
includes CORBA, boost::intrusive_ptr, std::shared_ptr etc.) I'm not
saying we have to make proton conform, but we should document how it
differs to save confusion.

1. A refcount is a count of the number of references (owning pointers)
to an object.

2. Objects are created with refcuont=1, the creator owns the first
reference.

3. If another owning reference is created, the refcount MUST BE
incremented.

4. The owner of a reference MUST decrease the refcount on dropping the
reference and MUST NOT use the pointer after refcount is decremented.
It no longer "owns" a reference.

5. The object MAY be deleted when refcount goes to 0 or MAY be pooled
for re-use but it MUST NOT be used by any code (other than the pooling
system if there is one)

6. You never examine the refcount (except for debugging) Either you own
a reference, which means refcount > 0, or you don't, which means you
MUST NOT touch the object, even to examine its refcount.

The fix mentioned above has this, which make no sense under traditional
refcounting:

        pn_incref(endpoint);
        pn_decref(endpoint);

Traditionally, this sequence is a no-op if the caller owns the
reference and is illegal if not. We need a clear statement of the
semantics of such sequences: when it it legal and what does it mean?
>From the fix it seems to be related to the "freed" and "referenced"
members, what exactly is the relationship?

Cheers,
Alan.



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


Mime
View raw message