Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!necntc!cullvax!drw
From: drw@cullvax.UUCP
Newsgroups: comp.lang.c
Subject: Fork and Exec
Message-ID: <1018@cullvax.UUCP>
Date: Thu, 2-Apr-87 14:00:09 EST
Article-I.D.: cullvax.1018
Posted: Thu Apr  2 14:00:09 1987
Date-Received: Sat, 4-Apr-87 15:30:32 EST
Organization: Cullinet Software, Inc., Westwood, MA
Lines: 28

ron@brl-sem.ARPA (Ron Natalie <ron>) writes:
> exec:   Replaces the currently running process, with the process
>    specified in it's arguments.  This obliterates the current process.
>    As a result, the only return from exec that the calling program will
>    ever see is an error (if it succeeds, the caller won't be there anymore).
>    If you would like to run a new process concurrently with the existing
>    one you need to fork first, and then obliterate one of the two processes
>    by exec-ing the new process.

Maybe I'm wrong here, but I believe that a more accurate statement is:

Exec replaces the current memory and register contents of the process
with the information specified in a particular executable file.  The
process itself retains its former identity (including, I beleive, its
open I/O channels, parent process, child processes, etc.).  Since the
*code* that called exec isn't around anymore, that call doesn't return
a value if exec succeeds.

There's a big difference between a process itself and the code that
the process happens to be running at the moment.

Dale

-- 
Dale Worley		Cullinet Software
UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw
ARPA: cullvax!drw@eddie.mit.edu
Un*x (a generic name for a class of OS's) != Unix (AT&T's brand of such)