Re: deferred deallocation of local objects

[Richard Frith-Macdonald]

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

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

> [snip]
> > 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?

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

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

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

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.