fork()/exec() or newproc()

[Max_4]

Hi everybody!

I was wondering why the usual process creation scheme for new different programs is fork() and exec() instead of always doing something like newproc(). What I mean, is for example when the initial system processes are created before init (for example pid 0), as I understand it the kernel does not utilize at this time fork()/exec(), rather it does something like creating everything from sratch. Since I assume it couldn't use at this very early time fork() and exec() since there is not yet a running process to make a copy of.

Why to go the overhead of always doing the 2-step approach (fork() and exec()) for creating new processes (for new different programs)instead of only doing it a 1 step approach (newproc() for example). I wonder if the reason for doing it in 2 steps is that doing it this way is less expensive as doing it in
a whole single step (newproc()).

I would also appreciate it if anyone could give some explanation/details of the initial genesis of systems processes. I mean how does the kernel creates new processes before it can even start using fork() and exec()?

Has it always been like this for creating processes for new different programs (I mean using fork() and exec()), or are there other forms?

Thank you very much in advance,

Manuel

[Oved]

Hey,

As far as I know, the memory image of the process is not always substituted. It uses the method of "copy on write", which causes the forkes process to use the same memory segments as the parent process, and only copy it if any information in these segments has been changed. It saves time because no need to copy a memory image, or create a new one. Copying is done only "by demand".

I know many unix systems work this way. I am not sure but I guess HP-UX works like this too.

Bye,
Oved

[A. Clay Stephenson]

From the earliest days on UNIX there has been a fork() and exec(). It is fundamental to the nature of UNIX that there be a close relationship between parent and child processes. Fork() and exec() make it possible to setup pipes between a parent and child and this mechanism depends upon file descriptors being duplicated and remaining open across exec()'s. No processes (other than init, PID 1) are truly standalone and all processes ultimately have init as an ancestor.

Some versions of UNIX have a lightweight version of fork() called vfork(). It was recognized that the vast majority of forks() are followed by an exec() so that the extra overhead of copying a running process was seldom needed. Vfork() allows the parent and child to actually shared data because only critical process data structures are actually made new and most of the process space is shared between parent and child. This could lead to much less overhead and faster forks BUT it could also lead to abuse. Vfork()'s should always be immediately followed by an exec() but if you didn't then you had two processes that implemented a poor man's version of interprocess communication. For example, if a variable was changed in the child process it was also instantly changed in the parent because it's the same memory area.

[Emil Velez]

Newproc is done inside the Fork and vfork system calls. Fork is just the system call that is externally used.

[Ted Buis]

A. Clay really addresses this one with vfork, but neglects to explicitly state that HP-UX has vfork, and, in my opinion, he needs to emphasize more strongly that fork has much greater overhead than vfork. So use vfork if possible.