Path: utzoo!attcan!uunet!bu.edu!xylogics!samsung!cs.utexas.edu!texbell!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.arch Subject: Re: vfork (was Re: Paging page tables) Message-ID: <22R45DG@xds13.ferranti.com> Date: 18 Jul 90 15:59:15 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> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 13 In article <5876@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) 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. 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. 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. -- Peter da Silva. `-_-' +1 713 274 5180.