Re: deferred deallocation of local objects

[Richard Frith-Macdonald]

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

> Hi,
> 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?
> Derek
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?