On Tue, Sep 22, 2009 at 09:58:43AM -0400, Pavel Ivanov scratched on the wall:
> Just a simple fact: you execute
> some code that uses memory in some way then you call fork() on Unix
> and you already have 2 absolutely different processes that can access
> the same data in memory.
Copy of the same data. The default fork() behavior is that the
child process is an exact copy of the parent process, but they do not
share memory. If the child makes a modification to it's memory
image, the parent's memory image is not effected, and so forth.
One of the reason most modern UNIX systems have reasonable fork()
performance is that they implement fork() with copy-on-write memory
pages. The child process uses the exact same memory image as the
parent, but if they write to memory a private copy of the page is
made first. This is the same way most shared libraries are loaded.
This tends to work very well, as the most common reason to call
fork() (outside of daemons) is to then call some version of exec(),
which trashes the whole memory image anyways.
Some OSes do support a version of fork() that allows the parent and
child to use the same memory image, but as I understand it, this is
not part of the POSIX standard. This can be used to support
something akin to heavy-weight threads, although with different PIDs,
file descriptors, and a mess of other things it gets... interesting.
Even more interesting than normal threads. IRIX had a pfork() call
that did that.
-j
--
Jay A. Kreibich < J A Y @ K R E I B I.C H >
"Our opponent is an alien starship packed with atomic bombs. We have
a protractor." "I'll go home and see if I can scrounge up a ruler
and a piece of string." --from Anathem by Neal Stephenson
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
