[MUD-Dev] Re: TECH: Distributed Muds

Derek Snider derek at idirect.com
Fri Apr 27 12:49:35 New Zealand Standard Time 2001

>From J C Lawrence, April 26, 2001 11:38 PM
> On Thu, 26 Apr 2001 21:52:23 -0400 
> Derek Snider <derek at idirect.com> wrote:

> If you have memory corruption problems you already have far worse
> problems that occassional page swaps.  Further, unless you do more
> than merely check the linkage pointers for first order correctness
> (either NULL or pointing to what looks like another node), you have
> absolutely no guarantees as to the state of the contents of any of
> those objects ("Yeah, this is a healthy horse.  See!  It has a
> bridle!").

I just said it would help catch corruption problems a lot sooner than
if you had corrupt memory you never touched at all.  I never said
memory corruption was "acceptable".
>> Also, in the case of a memory leak, leaked memory would be paged
>> out.

> It would be any way.

Not if that memory page was locked.

> Most Unix systems get very unhappy when approaching the limits of
> system/swap space.  Its got nothing to do with malloc()/sbrk()
> returning NULL, and it has everything with basic assumptions about
> edge conditions and the kernel coming under stress.  I'd be
> surprised if you got a clean core dump at the application level.
> I'd be mildly pleased if you got a clean panic and system dump as
> versus a spontaneous system reset or lock.

Depends on the Unix system.  BSD requires double the VM as RAM.  That
is a terrible waste of disk space.  With Linux you can get away with
using little or no VM.

MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list