9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] APE fork()
Date: Sat, 12 Aug 2006 13:55:30 +0100	[thread overview]
Message-ID: <342c529c14f5ca8b33589ef0cf85685e@terzarima.net> (raw)
In-Reply-To: <244c66f368a1f475aa51195812191aac@mail.gmx.net>

> I thought it does share the segments. And I think I saw this behaviour on Linux and some BSDs.

Linux:

NAME
       fork - create a child process

SYNOPSIS
       #include <sys/types.h>
       #include <unistd.h>

       pid_t fork(void);

DESCRIPTION
       fork  creates a child process that differs from the parent
       process only in its PID and PPID, and  in  the  fact  that
       resource  utilizations are set to 0.  File locks and pend­
       ing signals are not inherited.

       Under  Linux,  fork  is  implemented  using  copy-on-write
       pages,  so  the  only penalty incurred by fork is the time
       and memory required to duplicate the parent's page tables,
       and to create a unique task structure for the child.


of course, that's the Linux man page so it doesn't say what fork does, but
how it is implemented.  in fact, it doesn't share the data or stack segments;
clone by contrast will share everything.

perhaps BSD can shed more light:

     Fork() causes creation of a new process.  The new process (child process)
     is an exact copy of the calling process (parent process) except for the
     following:

	   o   The child process has a unique process ID.

	   o   The child process has a different parent process ID (i.e., the
	       process ID of the parent process).

	   o   The child process has its own copy of the parent's descriptors.
	       These descriptors reference the same underlying objects, so
	       that, for instance, file pointers in file objects are shared
	       between the child and the parent, so that an lseek(2) on a
	       descriptor in the child process can affect a subsequent read(2)
	       or write(2) by the parent.  This descriptor copying is also
	       used by the shell to establish standard input and output for
	       newly created processes as well as to set up pipes.

	   o   The child process' resource utilizations are set to 0; see
	       setrlimit(2).

	   o   All interval timers are cleared; see setitimer(2).


finally 7th edition UNIX, rather than its imitators:

     NAME
          fork  -  spawn new process

     SYNOPSIS
          fork( )

     DESCRIPTION
          Fork is the only way new processes are created.  The new
          process's core image is a copy of that of the caller of
          fork. The only distinction is the fact that the value
          returned in the old (parent) process contains the process ID
          of the new (child) process, while the value returned in the
          child is 0.  Process ID's range from 1 to 30,000.  This pro-
          cess ID is used by wait(2).

          Files open before the fork are shared, and have a common
          read-write pointer.  In particular, this is the way that
          standard input and output files are passed and also how
          pipes are set up.



  reply	other threads:[~2006-08-12 12:55 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-12 12:15 Sascha Retzki
2006-08-12 12:42 ` Victor Nazarov
2006-08-12 12:40   ` Sascha Retzki
2006-08-12 12:55     ` Charles Forsyth [this message]
2006-08-12 13:00     ` Victor Nazarov
2006-08-12 14:44   ` david bulkow
2006-08-12 15:09     ` Sascha Retzki
2006-08-12 15:14     ` Victor Nazarov
2006-08-12 15:15     ` Russ Cox
2006-08-12 15:43       ` Leonardo Valencia
2006-08-12 17:22       ` Brantley Coile
2006-08-12 17:54         ` erik quanstrom
2006-08-12 18:57           ` Bakul Shah
2006-08-12 19:54       ` Charles Forsyth
2006-08-12 20:07         ` erik quanstrom
2006-08-14  4:04           ` Iruatã Souza
2006-08-14  4:33             ` erik quanstrom
2006-08-14 14:41               ` Ronald G Minnich
2006-08-14 14:48                 ` erik quanstrom
2006-08-14 14:56                   ` Ronald G Minnich
2006-08-14 15:25                     ` erik quanstrom
2006-08-14 14:59                 ` Martin Neubauer
2006-08-14 15:33                   ` John Floren
2006-08-14 15:57                     ` erik quanstrom
2006-08-14 13:48       ` Dave Lukes
2006-08-15  4:19       ` William Josephson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=342c529c14f5ca8b33589ef0cf85685e@terzarima.net \
    --to=forsyth@terzarima.net \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).