Re: deferred deallocation of local objects

[Stefan Böhringer]

> 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.
Hm..., depending on the code there could be a race condition here,
depending on when the revended proxy is retained (before sending over
the encoded object to C or afterwards; but I haven't looked at the code
though).

>  By that time, a connection between C and A is already 
> > established (in
> > the initWithCoder: method at C side when building its NSDistantObject) 
Please explain what you mean by the connection C <-> A.
I read the situation strictly as A <-> B <-> C, i.e. all methods from C
-> A funnel through B.

> > 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

I think Richard's proposal to define behaviour of DO in these
exceptional cases is strictly required. From my experience the current
behaviour is different from what you propose, since the breakdown of one
connection brings down remote processes easily. At this time the
appropriate exceptions can be caught and handled. In our situation here,
e.g. I wouldn't see how C would learn about A dying if not B tells C
what happened. This could therefore break existing code...

> 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?
>