Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!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: <5899@titcce.cc.titech.ac.jp>
Date: 19 Jul 90 08:22:49 GMT
References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <5DL4SPD@xds13.ferranti.com> <5855@titcce.cc.titech.ac.jp> <180@array.UUCP> <5876@titcce.cc.titech.ac.jp> <22R45DG@xds13.ferranti.com>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 25

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

>> As I said about half a year ago, growing stack problem is not so
>> serious, because most programs (espacially, important system processes)
>> can do with the initially allocated stack segment and it is much less
>> likely to occur.

>And others can't. Consider, if you will, GCC.

I think death of GCC is not so serious.

>Again, is it possible to make use of a vfork() that doesn't clone the
>stack? I Can't think of any reason why it'd need to do that.

No, there is no reason.

>It'd make
>things convenient if you were to return in the child process (that is,
>if vfork can't be inlined), but it's not essential. You could always save
>and restore the top stack frame.

Correct.

						Masataka Ohta