Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: OS/2 vs AmigaDOS
Message-ID: <8905210019.AA24273@postgres.Berkeley.EDU>
Date: 21 May 89 00:19:29 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 32

:But very few OS'es have fork() and get along just nicely.  Most UNIX
:gurus will readily admit that roughly 90% of fork()'s are followed
:immediately by exec().  This is the reason for vfork() and fexec().
:
:For a lot of OS'es there is a single call that does this sort of
:thing, let's call it spawn().  It usually takes the name of a program,
:...
:yourself.  I would say spawn() is more useful than fork/exec, at least
:more widely used.  (I like UNIX, but you have to admit that its method
:of process creation is pretty unique)
:
:Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com)
:	We now return you to your regularly scheduled program.

	More widely used != more useful.  There was another thing you
mentioned about large programs wanting to 'spawn' small programs... you
missed your own remarks about vfork() for vfork() does not duplicate the
address space and thus has the same overhead no matter how large the 
program calling vfork() is.

	Believe me, that 10% is important.  It makes life easy for an 
incredible range of applications.

	The simple fact that spawn() is a subset of [v]fork/exec means
that spawn is NOT more useful.  For example, [v]fork/exec allows one
to taylor how the soon-to-be-exec'd process will be setup in terms of
stdin, stdout, stderr, ALL the file descriptors in fact.  How does one
do this with spawn()?  add more arguments to the call?  force the user to
setup stdin, out, etc... do the spawn(), and then fix his stdin, etc.. back
to what it was before?  And that is just one example...

					-Matt