Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!mit-eddie!snorkelwacker!usc!samsung!uunet!mcsun!ukc!pyrltd!root44!jgh
From: jgh@root.co.uk (Jeremy G Harris)
Newsgroups: comp.arch
Subject: Re: vfork (was Re: Paging page tables)
Summary: Add non-forked segments
Message-ID: <2340@root44.co.uk>
Date: 16 Jul 90 09:52:50 GMT
References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <Jul.14.14.12.32.1990.27493@pilot.njin.net>
Reply-To: jgh@root.co.uk (Jeremy G Harris)
Organization: UniSoft Ltd, London, England
Lines: 40

With all this discussion of possible modifications to Unix semantics, I
just have to put my oar in.   I hope I won't annoy anyone too much.

Background:   I like the power of fork/manipulate/exec.   I believe that
	      vfork was a stupid idea which should have gone away in
	      BSD4.4 .

My understanding of Masata's position:
              Preallocation of swap space (actually, virtual space, made
	      up of swap space plus real memory) upon fork is necessary to
	      avoid deadlock (or indefinite sleep for resources).   The
	      latter are bad and must be avoided.
	      Large processes exhibit the problem most obviously; the example
	      of an 80MB process wishing to fork/exec a subshell on a system
	      with a 100MB swap area (and, presumably, less than 60MB of
	      real memory) is given.

Proposal:     A segment type which is _lost_ by the child of a fork.

Discussion: 1) This is only a panacea, not a complete fix for the problem.

	    2) It muddles Unix fork semantics (the process is no longer
	      completely duplicated) but, IMHO, in a less objectional way
	      than vfork.

	    3) I'm assuming that the typical 80MB process didn't start out
	      that size but grew up to it by use of sbrk.

	    4) A whole raft of new system calls are needed, to obtain new
	      segments, grow them, modify the attributes, delete them,
	      share them.

	    5) Source modifications to existing programs are required.

	    6) mmap (or however you wish to spell it) does most of what is
	      needed anyway.

Comments, anyone?
-- 
Jeremy Harris			jgh@root.co.uk			+44 71 315 6600