On Wed, 31 May 2000, Patrick Dughi wrote:
> The above is certainly plainly put, and it's something I try
> not to say too often, regardless of how obviously true it is. The
> problems that I'm looking at though are the more complicated type. I
> consider myself a reasonably seasoned programmer, and i've worked in
> that capacity for Intel, Motorola, and now IBM. My code may not be
> the most graceful, and the patches I put out are not always of the
> highest order, but when something stumps me for more than 15 minutes
> on a codebase i've been using for how-ever-many-years, it registers in
> my head as a non-trivial problem.
The majority of problems classified as "non-trivial" are in relation to
memory allocation and deallocation. Specifically, the handling of bad
references to memory that has been freed or otherwise altered. CircleMUD,
as it stands, cannot be responsible for such things in an effective
manner. We could add reference counting, but this requires a special
syntax for assigning pointers and adds overhead to pointer uses. The
additional memory and processor overhead coupled with the fact that it's
really easy to circumvent make reference counting a non-option: it will be
ineffective. C++ makes it better, but it's still relatively easy to
circumvent and somewhat cost ineffective.
The other option to address this is some form of automated garbage
collection for CircleMUD. This is not a trivial addition by any stretch
of the imagination. And it's a problem that exists in C as well as C++,
although C++'s constructors and deconstructors /can/ help with some of the
book-keeping issues. In any software structured like a Mud, this becomes
an issue; you basically have a web of data with a handful of pointers
sprinkled across it. It's a very fragile backend for a project which is
going to receive significant third party alterations, especially from
programmers not so familiar with the nature of the beast. Garbage
collection helps shore this up by taking the memory handling away from the
user and just handling data which loses references.
Garbage collection is the only technology which fits the bill, but, as I
said, it's not a trivial addition by any stretch of the imagination.
Implementing a proper garbage collection algorithm can be time-consuming
and error-prone -- many programming languages, such as Python and C++, are
popular despite the glaring lack of garbage collection.
Short of writing your own garbage collection, I recently saw a Boehm
garbage collection library on Freshmeat. You might want to check it out
at http://www.hpl.hp.com/personal/Hans_Boehm/gc/. I've only used it thus
far to check for memory leaks in existing projects, which is a nifty
side-effect.
I would prefer garbage collection over reference counting, although you
seem to be championing the latter (which is what your system of storing on
deallocation amounts to).
-dak
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT