Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ucbvax!gorgo.UUCP!bsteve
From: bsteve@gorgo.UUCP (on Monster Island)
Newsgroups: mod.computers.68k
Subject: Re: Questions about the use of fork()
Message-ID: <8703211200.AA21533@gorgo.att.com>
Date: Mon, 23-Mar-87 04:05:58 EST
Article-I.D.: gorgo.8703211200.AA21533
Posted: Mon Mar 23 04:05:58 1987
Date-Received: Tue, 24-Mar-87 04:21:12 EST
Sender: mwm@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 25
Approved: info-68k@ucbvax.berkeley.edu

mwm@violet.berkeley.edu wrote - What I prefer is two system calls:

>1) fexec - run another process in a fork, with a block describing how
>the environment should be modified on the way. As stated above, this
>does what you want for a new process most of the time.

This seems highly reasonable and probably should have been there all
along.

>2) newthread - roughly, vfork in 4BSD. This creates another process
>that shares all resources with the parent. If either one does an
>exit() (or exec()) the other one just continues. YOu probably want to
>schedule the child to run first. Some technic for rendezvous will be
>required.

The only gotcha here is the issue of signal handling between processes.
If the parent ublock and ptable stuff stick around is it possible for 
the parent to take the signals meant for the child?

PS - this sounds very much like mach eh?


    Steve Blasingame (Oklahoma City)
    ihnp4!occrsh!gorgo!bsteve
    bsteve@eris.berkeley.edu