discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: deferred deallocation of local objects


From: Alex Perez
Subject: Fwd: deferred deallocation of local objects
Date: Mon, 13 Oct 2003 19:51:46 -0700

Begin forwarded message:

From: "Alex Perez" <address@hidden>
Date: October 13, 2003 1:08:10 PM PDT
To: <address@hidden>
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

reply via email to

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