Path: utzoo!attcan!uunet!decwrl!sdd.hp.com!samsung!cs.utexas.edu!uwm.edu!bionet!ames!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: <5962@titcce.cc.titech.ac.jp>
Date: 30 Jul 90 13:58:48 GMT
References: <920@dgis.dtic.dla.mil> <5830@titcce.cc.titech.ac.jp> <5931@titcce.cc.titech.ac.jp> <XYV4D8A@ggpc2.ferranti.com> <1990Jul24.194313.3258@esegue.segue.boston.ma.us> <=VW4JSA@xds13.ferranti.com>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 22

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

>Well that case can be dealt with (parent catches and discards interrupts
>around the spawn call), but the reverse case creates a race condition.

Can be. But, it is too tricky for Average programmers.

>This
>is not good, but it's also true that UNIX signals are *full* of such
>race conditions (hit ^C fast enough and you can blow away the shell).

That is untrue for BSD UNIX.

>What is needed is a "defer signals" state, along with "default, catch,
>and ignore". This would solve this race condition, and also the one where
>the signal handler gets interrupted before resetting the signal.

OK. You want to intruduce a new (to SysV) state of a process. Then, how
can you set the defer/don't-defer state of a child process with spawn?

						Masataka Ohta