Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!mit-eddie!rutgers!cs.utexas.edu!uunet!pdn!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.arch Subject: vfork() and swap space allocation Message-ID: <269DBEFB.583C@tct.uucp> Date: 13 Jul 90 12:30:51 GMT References: <5813@titcce.cc.titech.ac.jp> <2699E08D.117A@tct.uucp> <5844@titcce.cc.titech.ac.jp> Organization: ComDev/TCT, Sarasota, FL Lines: 44 According to mohta@necom830.cc.titech.ac.jp (Masataka Ohta): >In article <2699E08D.117A@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>This behavior is entirely consistent with other Unix resource >>management behavior. > >I don't know what variation of UNIX you know. So please tell me >what happens when there is not enough swap space with your >favorite UNIX. My favorite Unix is SCO Xenix/386 2.3. I haven't experimented with its behavior under memory and swap space exhaustion. I'm sure, however, that a SCO person will know how it works and can followup with that information. However, the behavior of my "favorite" Unix is irrelevant to this discussion. The Unix philosophy of resource usage is: "Pay as you go." Files are not pre-allocated, but dynamically extended. The data segment is not pre-allocated, but grows and shrinks on demand. Given this philosophy, the only consistent treatment of swap space is to allocate it when it is needed, and not before. Of course, dynamic allocation always introduces new failure modes. All C programmers should deal with malloc() failure and disk full conditions, but due to laziness it doesn't always happen. Likewise, a Unix kernel should deal gracefully with swap space exhaustion. If it doesn't, that indicates a bug in the kernel; it most certainly does NOT indicate a problem with the "pay as you go" philosophy, which has proven to be quite flexible and useful. >With vfork, such a situation never occur (except for stack segment), >becasue fork is denied. Note the "except" clause. Mr. Masataka himself here points out that vfork() is an incomplete solution, since a kernel with vfork() must be prepared to deal gracefully with swap space exhaustion due to stack modification. So vfork() does not eliminate the swap space contention inherent in new process creation. A kernel could replace vfork() with fork() and nothing of importance would be lost. In summary: I consider vfork() a botch. It is a half-hearted attempt to solve an unsolvable problem. Unix would be a better place if it were to disappear. -- Chip Salzenberg at ComDev/TCT ,