[Openib-windows] RE: Reference count as a solution to the problem of an object life time

[Fab Tillier]

> From: Tzachi Dar [mailto:tzachid at mellanox.co.il]
> Sent: Sunday, September 18, 2005 12:38 PM
> 
> Hi Fab,
>
> It seems that the only place in which I'm missing you is why there is a need
> for a "destroy complete" call-back. According to the method that I mention,
> there is no need for that I just call destroy and forget about the object. I
> haven't yet figured why the destroy call back is needed on your approach.

In your model, you define a standard interface for taking and releasing
references on objects.  When creating an object that invokes callbacks (B in
this example), the client passes in such an interface representing its context
object (A in this example).  B is returned with a reference held on behalf of
the caller.  Before being returned, B takes a reference on A and holds it as
long as it can have callbacks outstanding.  Once A destroys B, A can't go away
until B releases the reference on it, which it can only do once all callbacks
are delivered.  In this case, you don't need to specify a destroy callback at
destruction time since the dereference handler for A is equivalent.  You've just
specified the equivalent of the destroy callback at creation time.

In the current model, B doesn't take an interface to A, it takes an opaque
pointer as context, but has no knowledge of how to do anything with that
context.  When A decides to destroy B, it provides a destroy callback so that B
can properly synchronize callback delivery with destruction.  What A does in the
destroy callback is irrelevant to B - it just needs to do whatever is
appropriate.  When B is done being destroyed, it invokes A's destroy callback.
At creation time, A would take a reference on itself on behalf of B - this
eliminates the need to provide a call to take a reference on A internally to B.

The destroy callback serves as a final notification, from which the user
typically releases a reference on its internal context and performs any
necessary cleanup.  Think of the destroy callback as a deref for the context
provided when the object was created.

There's a reason the destroy callback and deref_al_obj have similar prototypes -
it is to allow a user to use an al_obj_t pointer as their context, and use
deref_al_obj as their destroy callback.  This is very similar to your proposed
model, except that in the IBAL model the deref() handler is provided when the
object is being destroyed rather than when it is being created.

Does that make any more sense?

I don't know if it's necessary/valuable to have the addref() function passed
into an object.  So I think the difference between the models comes down to
passing the deref handler at creation time or destruction time, which seems like
a pretty minor difference.

Whether a user waits for the deref/destroy callback or not is implementation
specific - neither of our methods forces any kind of synchronous or asynchronous
policy on our clients.

I don't know if forcing an object model into the API makes sense - that is, the
notion that all clients that expect callbacks must provide an interface to their
context that we define, as well as forcing all objects created by various parts
of the stack to expose the same general interface.  I would say I'm on the fence
about this, leaning towards simplicity (the current model) over flexibility (the
unified object model).

- Fab