[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: Wed, 15 Oct 2003 06:14:18 +0100

On Tuesday, October 14, 2003, at 10:17 PM, Alexander Malmberg wrote:

Richard Frith-Macdonald wrote:
On Monday, October 13, 2003, at 07:07 PM, Derek Zhou wrote:
In NSConnection.m -removeLocalObject:, all local objects are
deferred for deallocation by 30 seconds. According to the comments
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
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:


I meant problems caused by the current code that we are talking about ... not the original broken experimental version. That being said I don't know
of any bug reports linked to the original code change in any obvious way
(like timing).

Have you actually had a problem with this?

I have, but only for stuff that has, so far, been experimental.

Would reducing the deferral time fix the problems, or is that not
worth bothering with?

out a way of fixing it properly has been on my TODO list for a while,
but it has been blocked by other things.

Me too... I'm still stumped.

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

The biggest problem is that I don't have a system to reliably reproduce the original problem that the experimental code was intended to fix ... we are talking about intermittent faults to do with timing of things going on in
different processes/threads ;-(  Even the original experimental code
*seemed* to fix the original problem as I recall, but that must have been
a bogus effect of changing the scheduling by introducing extra calls
to get timestamps etc.
I guess if there are people on IRC who can reproduce the problem I
will need to learn to use IRC.

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

I don't think treating it as a nil object is good either. My strongest inclination is to stop deferring release of objects altogether, but of course that would
possibly break code depending on the current behavior.

reply via email to

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