Date: Fri, 16 Apr 1999 05:09:18 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: alk@pobox.com Cc: chuckr@picnic.mat.net, chat@FreeBSD.ORG Subject: Re: swap-related problems Message-ID: <3716476E.80DF2DBC@newsguy.com> References: <14102.8184.91918.375800@avalon.east> <Pine.BSF.4.10.9904151428030.18456-100000@picnic.mat.net> <14102.16644.178732.291963@avalon.east>
next in thread | previous in thread | raw e-mail | index | archive | help
Anthony Kimball wrote: > > I'm glad to be corrected where I err. But we are ANSI incompatible > if one cannot configure the system so that malloc failure semantics > conform to the C spec. Being able to rely upon ANSI C malloc failure > semantics is a contributory factor in being able to run a correctly > written application reliably. It is not sufficient, however, as > others have noted. In order to respond properly to the practical > inadequacy of mere ANSI conformance, the scope of the discussion has > expanded. Ok, here is the error of your ways. You are assuming that malloc(3) will return memory when there is none. This is incorrect. What happens is that processes get killed when the system find itself needing more memory than it has available. There are two ways of preventing that. One is pre-allocate all memory. This is not useful, because the memory available to each process ends up being very small. As an experiment, run X Free with the pre-zero pages flag set. The second way is to set limits to the memory the processes can use, without actually giving up on-demand allocation. FreeBSD supports this. Man login.conf(5). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Well, Windows works, using a loose definition of 'works'..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3716476E.80DF2DBC>