[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: Tue, 14 Oct 2003 04:35:09 +0100

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

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.

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?

reply via email to

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