[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: Fri, 17 Oct 2003 05:57:24 +0100

On Thursday, October 16, 2003, at 10:28 PM, Derek Zhou wrote:

Please bear with my ignorance, but I still fail to see the problem. From what I can see, all objects (including proxies) sent byref is retained locally on the behalf of the remote end of the connection; so they cannot get dealloced unless a remote release: message is received. So when process B sends a proxy to C, that proxy cannot get dealloced before C sends back a release message to B. By that time, a connection between C and A is already established (in the initWithCoder: method at C side when building its NSDistantObject) So even if there is a significant gap between 2a and 2b, B still cannot release the proxy and drop the connection to A, unless B invalidate the connection to A explicitly. To avoid the explicit droping of connection from happening, we can simply forbid any remote message that contains proxies from being oneway.
Any idea?

Good point ... unfortunately, the original problem was reported so long ago that I have no record of exactly when it occurred .... and I don't know how to
reproduce it now.

The only case that springs to mind is where B closes the connection to A, thus causing immediate release in A of all the objects retained by the connection to B. Apart from that situation, I think you are right about the way it should work ...
though of course there may be some case we've missed.

If this is indeed the case, a rather obvious modification of the current solution springs to mind ... instead of deferring all deallocations of local objects all the
time, just do it on connection shutdown.
ie when the connection is shut down, put all objects belonging to the connection
into a deferred deallocation pool.

This would be so *much* better than the current state, that I think we should go
ahead and make that change unless anyone else who's been looking at the
code knows better?

reply via email to

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