Date: Fri, 16 Jul 1999 13:16:40 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: dillon@apollo.backplane.com, sean.witham@asa.co.uk Cc: dcs@newsguy.com, drosih@rpi.edu, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Message-ID: <199907161716.NAA19250@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> I'm sorry, but when you write code for a safety related system you > do not dynamically allocate memory at all. It's all essentially static. > There is no issue with the memory resource. Besides, none of the BSD's are > certified for any of that stuff that I know of. Sometimes it's not feasible to statically allocate memory. You dynamically allocate all the memory you need at program initialization (and no, we don't want to manage a pool of memory ourselves - that's what the OS is for). Note that languages such as Ada raise exceptions when memory allocation fails. The underlying run-time relies on malloc returning null in order to raise an exception. Normally, programs written in Ada take great care to gracefully handle these exceptions. All the C programs that we've ever written also take great care in handling NULL returns from malloc. I have no problem with overcommit, but I can see the need that some folks have for turning it off. If you don't want to write the code to allow this, that's fine - you don't want/need it, so why should you? But if other folks see a need for it, let _them_ write the hooks for it :-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907161716.NAA19250>