Re: deferred deallocation of local objects

[Richard Frith-Macdonald]

On Saturday, October 18, 2003, at 08:20 PM, Derek Zhou wrote:

> > However, there is another error condition possible between A and B
> > without involving C:
> >
> > A vends O to B (oneway void) producing proxy P in B
> > B uses P and releases it, sending release message to A
> > A vends O to B again .... before receiving the release message.
> > A receives the release message and destroys local proxy releasing O
> > B receives reference to O from A and tries to use it ...
> >
> > Your solution would fix the original three-way problem, but not this
> > two way problem.
> Well, if A vends the object again, the retaincount at A should plus 
> one; then
> it takes 2 release messages from B to dealloc the object. IMHO, 
> tracking
> message sequence number in retain/release is overkill.
At the moment, the local object is retained only once (when initially 
vended)
and the retain count is not increased if it is vended again.  
Similarly, retains
and releases of the proxy in B are local to B until the proxy is 
actually
deallocated ... at which time a release message is sent back to A.
Working with multiple retains of the local object (once each time it is 
vended)
and multiple releases from the other end, would need quite a bit of 
extra work.
The connection in A would need to track the number of times the object 
had
been retained so that, on invalidation of the connection, it could 
release the
object a corresponding number of times.  The connection in B would  
need to
track the number of times it had received the object, and send that 
number of
release messages back when it no longer needs it.

This might easily be more work than watching the packet sequence 
numbers.
On the other hand, it looks a bit more intuitive.