[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: |
Tue, 14 Oct 2003 04:35:09 +0100 |
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?
Re: deferred deallocation of local objects, Derek Zhou, 2003/10/16