[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: deferred deallocation of local objects

From: Richard Frith-Macdonald
Subject: Re: deferred deallocation of local objects
Date: Sun, 19 Oct 2003 06:35:05 +0100

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]