Fwd: deferred deallocation of local objects

[Alex Perez]

Begin forwarded message:

> From: "Alex Perez" <aperez@student.santarosa.edu>
> Date: October 13, 2003 1:08:10 PM PDT
> To: <dzhou@chrontel.com>
> Subject: Re: deferred deallocation of local objects
>
> Derek,
> > 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
> The documentation for NSConnection can be found at:
> http://www.gnustep.org/resources/documentation/base/NSConnection.html
>
> You'll notice one of the maintainers names is Richard Frith-MacDonald. He
> is likely responsible for this braindead approach to problem-solving. RFM
> has a notorious reputation for fixing a bug and introducing two others in
> the process. His quality control is piss poor at best, and when you (even
> very nicely) address problems in -Foundation(Base) (which he maintains),
> he gets overly defensive and gives his canned, now-infamous response, "It
> works on my box."
>
> There are numerous citable instances where he will actually say "it works
> fine under Linux, and BSD is broken," when in fact it's not that BSD is
> broken at all, just that the implementations of things can be different.
>
> I urge you to bitch about this as much as humanly possible, because I
> think it's yet another perfect example of a braindead implementation on
> the part of RFM, and while we appreciate his contributions, he needs to be
> called to task for his shoddy work, assuming this is his fault, which it
> in all likelyhood is.
>
> Alex Perez