Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!gvlv2!tredysvr!barry
From: barry@tredysvr.Tredydev.Unisys.COM (Barry Traylor)
Newsgroups: comp.arch
Subject: Re: vfork (was Re: Paging page tables)
Summary: Spawn's a nice idea but not practical for Unix
Message-ID: <855@tredysvr.Tredydev.Unisys.COM>
Date: 14 Jul 90 01:32:04 GMT
References: <5DL4SPD@xds13.ferranti.com> <5855@titcce.cc.titech.ac.jp> <Q=M4GG5@xds13.ferranti.com>
Organization: Unisys Corporation,  Tredyffrin, PA
Lines: 27

In article <Q=M4GG5@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>
>However, there are any number of "rational definitions of spawn", since
>outside of UNIX it is about the only process creation primitive that
>exists. It's also how just about every thread implementation that I
>know of implements thread creation... including Mach. You can find as
>many varieties of spawn as you wish by perusing other operating system's
>programming manuals. It would be redundant for me to duplicate any
>particular definition here.

You point up one of the difficulties of defining a "standard" spawn for Posix
(tm IEEE), in that there are so many different forms.  Thread creation is a
different case, and I agree that a "spawn-like-function" is a better way to
go.  The primary difficulty of spawn w/r/t Unix (tm, AT&T) or Posix is that 
Unix has never had a "task object" that could be manipulated.  Instead, 
fork() was used and the manipulation was done directly (and implicitly) to 
the new process.

At this point, coming to any sort of agreement on how to define a task
object, and how to manipulate it in such a way as to emulate the
possibilities of fork()/exec[ve](), would be pretty close to impossible.  On
the other hand, a good implementation of vfork() can avoid most of the cost
of a fork() while losing very little of its flexibility.

Barry Traylor
Unisys Large A Series Engineering (read: Big Mainframes)
barry@tredydev.unisys.com