Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!mit-eddie!bu.edu!rpi!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!sun-barr!ccut!titcca!cc.titech.ac.jp!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.arch
Subject: Spawn is impossible to define (was Re: vfork)
Message-ID: <5929@titcce.cc.titech.ac.jp>
Date: 23 Jul 90 04:40:06 GMT
References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <5DL4SPD@xds13.ferranti.com> <5855@titcce.cc.titech.ac.jp> <Q=M4GG5@xds13.ferranti.com> <5893@titcce.cc.titech.ac.jp> <XRS4OLF@xds13.ferranti.com>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 25

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

>> In spite of my request to actually show a "rational definition of spawn",
>> no one has ever shown it.

>OK, what capabilities in the child process need to be modified by the parent
>process, but can not be non-destructively changed by the parent.

Thanks for showing the inherent complexity and impossibility of defining
spawn call, again.

>In UNIX the most important parts are current directory, user ID, open files,
>and environment variables. Environment variables are already explicitly passed
>by exec*e.

HOW DO YOU THINK ABOUT SIGNALS?

>Open files can be handled by passing a vector of fds to be stuck into the
>child's file descriptord.

It reminds me of a AEGIS (yes, I know of other OSs). It was real pain
to use that OS.

						Masataka Ohta