Date: Thu, 15 Apr 1999 14:50:02 -0500 (CDT) From: Anthony Kimball <alk@pobox.com> To: chuckr@picnic.mat.net Cc: dcs@newsguy.com, chat@FreeBSD.ORG Subject: Re: swap-related problems Message-ID: <14102.16644.178732.291963@avalon.east> References: <14102.8184.91918.375800@avalon.east> <Pine.BSF.4.10.9904151428030.18456-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoth Chuck Robey on Thu, 15 April: : > I understand this. I concieve the purpose of this thread as being : > a clear determination of the best known way to allow correctly : > written code to run reliably when, for reasons perhaps out of the : > control of the application, memory becomes overcommitted. : : It might have been that, if on the second line of your original post you : didn't claim we were ANSI incompatible. As it was, it sounded much like : chicken little yelling the sky was falling. Your position now seems to : have changed quite a bit. 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. My understanding of the state of play is this: While mmap-backed malloc suffices to provide ANSI C conformant malloc failure semantics, and this can be handled best at the library level, the best proposed solution to the broader practical problem is to provide a kernel-level facility to specify that a fork (and all children, recursively?) are to be backed by a specific file. In my opinion, this is not detectably better (in the sense of being less intrusive to implement) than a kernel facility to reserve swap for a fork (and all children, recursively?). 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?14102.16644.178732.291963>