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: <5971@titcce.cc.titech.ac.jp>
Date: 1 Aug 90 03:57:07 GMT
References: <5962@titcce.cc.titech.ac.jp> <OP-4G62@xds13.ferranti.com>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 60

In article <OP-4G62@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.

>So, from my own observation of such code culled from the net, is signal
>handling and fork/exec in any case.

You seems to be thinking quality of average programmers very low.
Then, surely, broken spawn is as good as vfork-exec to them, because
they can use neither of them.

>> >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.
>
>That's using BSD's "reliable signales", which are an extension to standard
>UNIX signals.

Then, you don't know BSD's reliable signal. You don't have to use extension
such as sigvec() explicitely. In BSD, standard UNIX system call signal()
itself is reliable.

>I'm sure that they also have the ability to solve the problem
>you originally posited.

But you are wrong. The problem is still impossible to solve.

You shouldn't be sure about such a complex thing without actually
solving it.

>> OK. You want to intruduce a new (to SysV) state of a process.
>
>No, of a signal. A state that is also useful in that it solves the race
>conditions inherent in generic UNIX signals without adding the unwanted
>complexity of BSD's reliable signals system. KISS.

And you can't still solve the case I mentioned.

>> Then, how
>> can you set the defer/don't-defer state of a child process with spawn?

>You don't, because it's not meaningful any more than setting the catch/
>don't catch state of a signal. Neither is useful without a signal handler,

Catch/don't-catch? Why did you change wording? Are you trying to confuse me?
Ignoring of signals and defering of signals are different things.

We are talking about a signal state of defer/don't-defer. The state is
meaningful even without signal handler, because, during the state of
defer, we can setup an appropriate signal handler.

So, defer/don't-defer state IS meaningful without signal handlers.

						Masataka Ohta