[Home] [Groups] - Message: [Prev in Group] [Next in Group]
19049: RE: [MUD-Dev] Re: TECH: Distributed Muds
[Full Header] [Plain Text]
From: "Derek Snider" <derek@idirect.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Fri, 27 Apr 2001 12:49:35 -0400
References: [1]
Organization: Kanga.Nu
From J C Lawrence, April 26, 2001 11:38 PM
> On Thu, 26 Apr 2001 21:52:23 -0400
> Derek Snider <derek@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@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev