Index: doc/overview2.sgml
===================================================================
RCS file: /cvs/src/src/winsup/doc/overview2.sgml,v
retrieving revision 1.20
diff -u -p -r1.20 overview2.sgml
--- doc/overview2.sgml 18 Sep 2010 15:58:46 -0000 1.20
+++ doc/overview2.sgml 3 Nov 2011 16:27:36 -0000
@@ -346,6 +346,60 @@ cases, stubs of each of these Win32 proc
their exec'd Cygwin process to exit.
+
+Problems with process creation
+
+The semantics of fork require that a forked
+child process have exactly the same address
+space layout as its parent. However, Windows provides no native
+support for cloning address space between processes and several
+features actively undermine a reliable fork
+implementation. Three issues are especially prevalent:
+
+
+DLL base address collisions. Unlike *nix shared
+libraries, which use "position-independent code", Windows shared
+libraries assume a fixed base address. Whenever the hard-wired
+address ranges of two DLLs collide (which occurs quite often), the
+Windows loader must "rebase" one of them to a different
+address. However, it may not resolve collisions consistently, and
+may rebase a different dll and/or move it to a different address
+every time. Cygwin can usually compensate for this effect when it
+involves libraries opened dynamically, but collisions among
+statically-linked dlls (dependencies known at compile time) are
+resolved before cygwin1.dll initializes and
+cannot be fixed afterward. This problem can only be solved by
+removing the base address conflicts which cause the problem,
+usually using the rebaseall tool.
+
+Address space layout randomization (ASLR). Starting with
+Vista, Windows implements ASLR, which means that thread stacks,
+heap, memory-mapped files, and statically-linked dlls are placed
+at different (random) locations in each process. This behaviour
+interferes with a proper fork, and if an
+unmovable object (process heap or system dll) ends up at the wrong
+location, Cygwin can do nothing to compensate (though it will
+retry a few times automatically). In a 64-bit system, marking
+executables as large address-ware and rebasing dlls to high
+addresses has been reported to help, as ASLR affects only the
+lower 2GB of address space.
+
+DLL injection by
+
+BLODA. Badly-behaved applications which
+inject dlls into other processes often manage to clobber important
+sections of the child's address space, leading to base address
+collisions which rebasing cannot fix. The only way to resolve this
+problem is to remove (usually uninstall) the offending
+app.
+
+In summary, current Windows implementations make it
+impossible to implement a perfectly reliable fork, and occasional
+fork failures are inevitable.
+
+
+
+
Signals
When
a Cygwin process starts, the library starts a secondary thread for