Xref: utzoo comp.sys.ibm.pc:29009 comp.sys.amiga:34036
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!ames!apple!versatc!leadsv!laic!nova!darin
From: darin@nova.laic.uucp (Darin Johnson)
Newsgroups: comp.sys.ibm.pc,comp.sys.amiga
Subject: Re: OS/2 vs AmigaDOS
Keywords: Operating Systems, Religion WRT computers
Message-ID: <560@laic.UUCP>
Date: 18 May 89 18:33:19 GMT
References: <2134@iitmax.IIT.EDU> <5625@microsoft.UUCP> <917@mks.UUCP> <9616@watcgl.waterloo.edu> <925@mks.UUCP> <2762@csccat.UUCP> <953@mks.UUCP>
Sender: news@laic.UUCP
Reply-To: darin@nova.UUCP (Darin Johnson)
Organization: Lockheed AI Center, Menlo Park
Lines: 28

>I have to agree with you, for a standard application, threads may well
>be more useful.
>However, for your average system program (e.g. shell, editor)
>fork/exec is more useful.

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,
and possibly an input and output stream.  This type of call can be made
to work on nearly any multitasking system, even if fork() is not available.
This command works great for editors and mailers when you want to create
a "subshell" without leaving the application.  Many non-unix shells use
a similar method to run commands in the background (many don't bother
with a new process for each command).  And if you have a huge application
that wants to spawn a tiny program, this is more efficient than fork
(except for intelligent fork()s that use copy on modify).  The nice
thing is that this type of call can be built on top of other
multitasking primitives.  If you need the primitive calls they are there,
but for the general case you don't have to do all the hard work
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.