Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!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: <5855@titcce.cc.titech.ac.jp>
Date: 12 Jul 90 15:30:57 GMT
References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <5DL4SPD@xds13.ferranti.com>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 30

In article <5DL4SPD@xds13.ferranti.com>
	peter@ficc.ferranti.com (Peter da Silva) writes:

>> 1) An utterly broken implementation where some important system
>> process (such as inetd, ypbind or sendmail) may killed if there
>> is not enough swap space.

>Alternatively, put the program in a wait state until swap space is available.
>Deadlocks are possible, but unlikely. Indefinite deferment is more likely,

No.

Once swap space shortage occurs, it will tend to occur continually
until some large process exits. So, if all such processes put in
wait states (which is very likely to occur, because active process
often requires new pages) the situation is deadlock.

>and that can be handled by queueing input.

What do you mean by "can be handled by queueing input."?

>4) A really efficient implementation with spawn.

As far as I know, it is impossible to implement spawn, because there
is no rational definition of spawn. To eliminate repetition of unnecessary
fruitless discussion, you should show a reasonable and complete (at least
as complete as UNIX man page) definition of spawn if you want to claim
it possible. Also, it should be more beautiful than vfork, of course.

						Masataka Ohta