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

[Tzachi Dar]

1) This seems error prone to me.  If you no longer want an object and
decrement its reference count, you could very well destroy the associated
context.
This is exactly the point: you want an object keep a pointer to it and have
a reference, you don't want an object, remove the reference and get rid of
the pointer. 
> Getting a callback after this is likely to crash.  
No way, the one who is calling the callback should be having a reference,
other wise he can't make the call.
> This model seems to increase the complexity for a ULP.  How can a ULP
unload?
This is indeed a point that should be solved and I have a solution for it, I
just don't want to make things too complicated. Believe me that there is a
solution that doesn't require a complete change of the model. (We can talk
about it in a different thread if anyone wants).
 How can it signal the CM that it will no longer be around to receive a
callback? 
An app that allocates an object can't simply forget about it.  Using this
method, the creator of the object will never know if a callback will occur
for some past created object, so can never cleanup anything associated with
the object.
The creator of the object doesn't have to know when the object is destroyed;
it just has to know that it will be destroyed. The object will clean all
it's resources once the object is cleared from memory. 
 
 
-----Original Message-----
From: Sean Hefty [mailto:sean.hefty at intel.com] 
Sent: Wednesday, September 21, 2005 8:18 PM
To: 'Tzachi Dar'; 'Fab Tillier'; openib-windows at openib.org
Subject: RE: [Openib-windows] RE: Reference count as a solution to the
problemof an object life time
 
I want to give an example to this: "I" create an object (and set it's
reference to 1). I give this object to the CM (IB_CM_LISTEN(obj)). The CM
wants to do a call back in the future, so he increases the reference count
to 2. Now I forget about the object and release my reference (back to 1).
The CM receives a request and wants to call my call back. He does this
without increasing the reference. I use the object during the callback. If I
want to keep it I increase the reference count. Now let's say that after 50
callbacks he has some error. He calls the error callback and releases his
reference count since he doesn't want to use the object any more. The
reference went to 0 and the object is being destroyed (release understands
that the reference has reached 0 and call the destroy automatically). 
This seems error prone to me.  If you no longer want an object and decrement
its reference count, you could very well destroy the associated context.
Getting a callback after this is likely to crash.  This model seems to
increase the complexity for a ULP.  How can a ULP unload?  How can it signal
the CM that it will no longer be around to receive a callback?  An app that
allocates an object can't simply forget about it.  Using this method, the
creator of the object will never know if a callback will occur for some past
created object, so can never cleanup anything associated with the object.
- Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20050921/a2cc04fa/attachment.html>