[RFC] cbdata NG

On 07/07/2012 12:04 AM, Alex Rousskov wrote:
> P.S. I am also concerned what happens when cbdataReferenceDone() reaches
> zero lock counter for a non-POD object. Will need to get some sleep
> before researching that :-).

Confirmed. cbdataReferenceDone() and friends will not call destructors
before deallocating memory for the unlocked and invalid object, as
suspected. This means that rewriting cbdataAlloc and cbdataFree macros
will not be sufficient to solve the problem of dirty non-POD objects
being deallocated without their destructors called to do required
cleanup (such as decrement reference counts for the resources they
hold). We must rewrite all cbdata*() macros.

Both Henrik and Amos mentioned that a transition to something like
RefCount+invalidation would be desirable. I agree. However, there is one
big problem with accomplishing that. We have lots of code that does,
essentially, this:

    lowLevelHandler(... void *callback_data) {

        void *data = cbdataReference(callback_data);

        ... time passes ...
        ... this is usually in some "exit" handler function ...
        ... but given here to simplify illustration ...

        cbdataRerefenceDone(data);
    }

As you can see, cbdataRerefenceDone() operates on a typeless data.
Nothing we can do to cbdata*() will call the true data destructor(s) in
this context. To solve thus, we must replace void* with a real type.
Since low-level handlers (e.g. Comm) cannot know high-level types, this
real type must be a base class with a virtual destructor.

I can post specific changes if there are no better ideas.

Do we have some callback data that is a true POD and must remain a POD
for some low-level reasons like feeding it to system calls? Wrapping
that one would need special care because we cannot use inheritance (it
adds a virtual table pointer at an unknown location of object memory).

Assuming these changes are of high-enough quality to be accepted, will
they be propagated to v3.2? I would hate creating such a big difference
between trunk and v3.2 for no good user-visible reasons!

Thank you,

Alex.
Received on Sat Jul 07 2012 - 16:25:05 MDT