[Home] [Groups] - Message: [Prev in Group] [Next in Group]
1806: Re: [MUD-Dev] Languages
[Full Header] [Plain Text]
From: "Miroslav Silovic" <silovic@srce.hr>
Newsgroups: nu.kanga.list.mud-dev
Date: Mon, 26 May 1997 23:52:26 +0200 (MET DST)
References: [1]
Organization: Kanga.Nu
> [Miro:]
>
> :(I consider GC to be the key feature of a MUD language, after
> :incredible ammount of time wasted on tracing leaks, bad access,
> :and similar problems. C++ constructors and destructors alleviate
> :this problem, but if you run out of luck, not even Purify will
> :save you.)
>
> Is that in the MUD language, or the language used to implement the MUD?
>
> Neither of mine has a garbage collector. The implementation language is
> like C with syntax. The MUD language has types like strings, lists, tables,
> etc. mostly stored in the database (not strings, which are not use-
> counted). When a db entity's usecount goes to zero, it is deleted, and
> the use-counts of anything it points at decremented, etc.
Refcounting actually /is/ a form of garbage collector (provided that your
access mechanism disallows cycles... you did think of that little problem?)
But yes, I wanted to say that gc is absolutely essential for MUD language.
As for the language in which the MUD is implemented, gc still helps a lot
if you're not in too much hurry. I did some debugging of /really/ weird
refcounting problems... basically refcounts begin to suck when you find out
that Purify won't always tell you when they hang. :/
My experience with true gc (I used conservative gc with a trully nasty
brew of C and Scheme code) is that you really *NEVER* get bugs that are
hard to find. The worst case, when I forget to mark refs that shouldn't
be swept cause crash so quickly that you can easily see the cause from
the coredump.
Miro