fork() - The natural implementation of system calls

I fork()'ed again.
For all of you who don't know what fork() is: It is a system call.
Here's a short quote out of the manual page of fork() plus some explanations of what they mean in real life:

FORK(P)                    POSIX Programmer's Manual                   FORK(P)

NAME
       fork - create a new process

SYNOPSIS
       #include <unistd.h>

       pid_t fork(void);

DESCRIPTION
       The  fork() function shall create a new process. The new process (child
       process) shall be an exact copy of the calling process (parent process)
       except as detailed below:

This far, everything should be clear. At least one parent process creates a child process. In real life, a child process looks something like this:



Per definition, a child process differs in some points from the parent processes. The details are explained below:

        * The child process shall have a unique process ID.

This can be accomplished by giving the child process its own name, e.g. if your name is Sepp, don't call your child process Sepp too.

        * The  child  process ID also shall not match any active process group
          ID.

Don't call it like any group you know, e.g. colleagues, neighbors, ...

        * The child process shall have a different parent  process  ID,  which
          shall be the process ID of the calling process.

This one translates to the surname and usually can be realized easily.

        * The  child  process  shall  have  its  own copy of the parent's file
          descriptors.  Each of the child's file descriptors  shall  refer  to
          the  same open file description with the corresponding file descrip-
          tor of the parent.

Give your child process a separate room in your house/flat/whatever but make sure that its newly created room is accessible from your own rooms.

        * The  child  process  shall have its own copy of the parent's message
          catalog descriptors.

Teach him/her your language. This may take a while but is usually very effective later on.

        * The  time  left  until an alarm clock signal shall be reset to zero,
          and the alarm, if any, shall be canceled; see alarm() .

Don't use alarm clocks near your child process rooms otherwise you won't have recreative nights anymore.

        * File locks set by the parent process shall not be inherited  by  the
          child process.

It's in the nature of a child process to disobey your rules and to not pay attention to forbidden items and locations so don't blame it for doing thinks like that.

        * The  set  of signals pending for the child process shall be initial-
          ized to the empty set.

Well, that's clear, it can't process it anyway the first few weeks.

        * No asynchronous input or asynchronous  output  operations  shall  be
          inherited by the child process.

Child processes tend to do all things simultaneously anyway, so asynchronous input or output is not available in the first few years...


I hope you all un-fork()'ed guys out there now realize what it really means to fork ;)
BTW: The main purpose of this blog entry was to present some pictures of our newest unborn child process.

Click here to enter the gallery