Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!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: Re: Spawn is impossible to define (was Re: vfork)
Message-ID: <5931@titcce.cc.titech.ac.jp>
Date: 24 Jul 90 05:24:25 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> <5929@titcce.cc.titech.ac.jp> <E5V4K+F@xds13.ferranti.
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 22

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

>In article <5929@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>> Thanks for showing the inherent complexity and impossibility of defining
>> spawn call, again.

>Two more arguments than "exec" is too much complexity?

Two more arguments is not complex.

>Signals can be reliably saved and restored, so they can continue to be
>inherited across spawn as they are now inherited across fork and exec.

If a parent process want to catch some signal (whose default action
is termination) and a child process want to ignore it, how can it
be done? Parent process should not discard delivered signal, of
course.

BTW, signal is not an only thing you miss.

						Masataka Ohta