Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!lll-winken!sun-barr!ccut!titcca!cc.titech.ac.jp!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.arch
Subject: Re: vfork (was Re: Paging page tables)
Message-ID: <5845@titcce.cc.titech.ac.jp>
Date: 12 Jul 90 04:28:06 GMT
References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <1990Jul11.191235.8117@cs.rochester.edu> <269B8E4F.27941@ics.uci.edu>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 32

In article <269B8E4F.27941@ics.uci.edu>
	baxter@zola.ics.uci.edu (Ira Baxter) writes:

>The
>UNIX-wait-till-I-need-it scheme suffers from the potential of deadlock
>over swap requirements when they finally appear.

OK, you understand a problem here.

>But one can walk a
>middle road: allocate the space, but only assign it incrementally when
>COW actually happens.  Space allocation given a fixed supply is a
>simple matter of adjusting a semaphore count.

As I already mentioned, the problem with such an approach is that
a large process can not fork.

If there is only 100MB swap space, and a 80MB process want to fork
just to exec a small program such as shell, 160MB of swap space must
be temporarily allocated. It is impossible.

>If one wanted to mix
>the policies, all you need is a hint to vfork (or whatever) that says
                                         ^^^^^
>"allocate now" or "delay allocation".

A hint to vfork???

You must have misunderstood something. If we use vfork, there is
no problem.

				Masataka the-protector-of-vfork Ohta