[MUD-Dev] Re: TECH: Distributed Muds
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
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
> 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