Date: Fri, 16 Jul 1999 10:42:28 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Daniel Eischen <eischen@vigrid.com> Cc: sean.witham@asa.co.uk, 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: <199907161742.KAA20451@apollo.backplane.com> References: <199907161716.NAA19250@pcnet1.pcnet.com>
next in thread | previous 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
Simply set a resource limit.
You are making the classic mistake of assuming that a fail-safe in the
O.S. must be integrated all the way down into the user level when,
in fact, it is simply a matter of setting a resource limit.
When you are running an embedded system and have full control over the
software being run, setting resource limits will do what you want. By
doing so you are effectively managing the software modules on a
module-by-module basis and not allowing one module to indirectly effect
another. This is what you want to do in an embedded system: You do
not want to create a situation where a failure in one module cascades
into others.
-Matt
Matthew Dillon
<dillon@backplane.com>
: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?199907161742.KAA20451>