Re: deferred deallocation of local objects

[Richard Frith-Macdonald]

On Monday, October 13, 2003, at 07:07 PM, Derek Zhou wrote:

> Hi,
> In NSConnection.m -removeLocalObject:, all local objects are 
> unconditionally
> deferred for deallocation by 30 seconds. According to the comments 
> there, it
> is to avoid oops when the remote end vend the object onwards. Why is 
> this
> nessesary? It looks rather ugly to me. 30 seconds is a pretty long 
> time; if
> one keeps pushing objects to the far end it can consume huge amount of 
> memory
> or even get out-of-memory condition. If we do not have elegant 
> solution at
> least we should make it per-application overridable by using defaults.
> Derek

I think it *is* a pretty horrible hack ... and the only justification 
for keeping it is that
some people had problems without it and nobody has reported problems 
caused
by it ... I'd love to see a better solution contributed.

The problem it (partially and poorly) addresses is the case when 
process A
vends O to B, then B vends O to process C and drops the connection to A.
When the connection between A and B is dropped, the local object in A is
no longer retained by B so A thinks it can release it if C has not 
retained it
in time. Keeping the objects for a while closes this window in practice 
(though
of course in theory process C could take over 30 seconds to contact A 
and
retain the object, so it's not guaranteed to solve the problem for all 
cases).
The reason people don't have trouble with building up huge numbers of
objects waiting for deallocation is that they tend not to send large 
numbers
of *different* objects (byref) over a connection.

Have you actually had a problem with this?
I'd rather have a good fix (or even remove the existing hack 
altogether) than
a user default to modify the poor fix.  In fact I'd rather like to 
remove the existing
code, though a compromise might be to use a much shorter deferred 
deallocation
time, which would still mostly close the window, but not leave much 
time for
a build up of objects.

One option I've considered is, where this problem arises (ie process C
connects to A in order to send a message to O, and O has been 
deallocated)
is to treat  it like sending a message to a nil object rather than 
raising an
exception. Of course, that's really just changing the way things fail,
but it might be better?