9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@9fans.net
Subject: Re: [9fans] _tos puzzle
Date: Thu,  8 May 2008 18:50:33 +0100	[thread overview]
Message-ID: <93980d7f9ad6eacb9c95c00776e2cad8@terzarima.net> (raw)
In-Reply-To: <FA6B86C4-2292-47A9-BFCE-DA0F2318F099@kix.in>

> The clone(2) system call in linux allows for creation of child
> processes that share address space with its parent, with the exception
> of the stack segment. I believe that should do?

>Wouldn't the CLONE_VM flag do this?

no.

Linux shares the stack segment too: the underlying system call shares everything (given CLONE_VM),
and the clone library function simply switches the stack pointer to the address you give it,
but that's still in the shared address space.

rfork by contrast shares data and dss, but gives parent and child private [logical] copies of the stack.
that is, both initially have the same stack addresses and contents, but can subsequently change them
independently.  both stacks can grow.

clone therefore creates different memory contents for parent and child, with completely different
stack addresses and contents, and the code the child executes is distinguished by the clone call itself.

by contrast, rfork gives parent and child the same initial memory contents, sharing only the data,
and rfork's caller determines (based on the process ID return value) which does what after the call.




      parent reply	other threads:[~2008-05-08 17:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-08 16:18 Anant Narayanan
2008-05-08 16:41 ` Russ Cox
2008-05-08 17:13   ` Anant Narayanan
2008-05-08 17:24     ` Russ Cox
2008-05-08 17:40       ` Steven Vormwald
2008-05-08 19:19       ` Anant Narayanan
2008-05-08 20:33         ` Russ Cox
2008-05-09  5:30           ` Anant Narayanan
2008-05-09 13:08             ` Russ Cox
2008-05-08 17:50     ` Charles Forsyth [this message]

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=93980d7f9ad6eacb9c95c00776e2cad8@terzarima.net \
    --to=forsyth@terzarima.net \
    --cc=9fans@9fans.net \
    /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).