From owner-freebsd-hackers Tue Feb 27 0:22:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id C4CD937B718 for ; Tue, 27 Feb 2001 00:22:51 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f1R8Mkw54670; Tue, 27 Feb 2001 00:22:46 -0800 (PST) (envelope-from dillon) Date: Tue, 27 Feb 2001 00:22:46 -0800 (PST) From: Matt Dillon Message-Id: <200102270822.f1R8Mkw54670@earth.backplane.com> To: Arun Sharma Cc: hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. References: <200102260529.f1Q5T8413011@curve.dellroad.org> <200102261755.f1QHtvr34064@earth.backplane.com> <200102270624.WAA17949@c62443-a.frmt1.sfba.home.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> things work. Then try coding conditionals all the way through to fix :> it... and don't forget you need to propogate the error condition back :> up the procedure chain too so the original caller knows why it failed. : :So, it all comes down to reimplementing the UNIX kernel in a language :that supports exceptions, just like Linus suggested :) : : -Arun Not really. UNIX works just fine, it gives you plenty sufficient control over your environment and you can write your programs pretty much in whatever language you like. But no amount of OS control will magically save a badly written program from itself. The best you can hope for is to reduce the collateral damage by setting appropriate resource limits. Allowing a program to run the OS itself out of VM, with or without overcommit, is (being generous) just plain dumb. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message