Re: deferred deallocation of local objects

[Alexander Malmberg]

Richard Frith-Macdonald wrote:
> 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
[snip]
> 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 ...

This is false. The implementation was, afaict, broken for the first 8
months after it was written (it was added, marked experimental,
2002-12-10, and I fixed it 2003-07-08). This caused user-level problems
that were reported several times, starting (from what I've been told)
the day after it was committed, and the last of which was:

http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4008&group_id=99

[snip]
> Have you actually had a problem with this?

I have, but only for stuff that has, so far, been experimental. Figuring
out a way of fixing it properly has been on my TODO list for a while,
but it has been blocked by other things.

> I'd rather have a good fix (or even remove the existing hack
> altogether) than
> a user default to modify the poor fix.

True. A user default is the wrong way of solving this problem.

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

Well, it should be fixed properly as soon as possible, but since it's
been broken most of the time anyway, I don't think it'd hurt to remove
it until that's done, although lowering the timeout would be safer.
Testing would be important (GNUMail and Ian_J in #GNUstep are a good
testing pair :).

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

This would just temporarily introduce another broken behavior, so that
developers would have to deal with three different behaviors (the old
broken behavior, the new broken behavior, and, eventually, the correct
behavior). Keeping the current broken behavior until it's fixed properly
is better, IMHO.

- Alexander Malmberg