OSDev.org

fork() has always been a massive problem in porting Unix software to other operating systems. Unless the system has some similar feature (cloning the address space with CoW semantics), it's next to impossible to emulate.

That's just something you should be aware of if you're writing POSIX software with an eye on portability on POSIX-emulating systems.

I remember that a huge majority of the patches necessary to make POSIX software run on the Amiga consisted of replacing fork() with vfork() et al. - everything else was a piece of cake to emulate, but fork() was a female dog of questionable repute.

Hobbes wrote:As a side note, I have always found fork() quite a strange function. Most of the times, all the child does is spawn another program and exit itself. Why create a complete copy of the parent's address space to do that?

On most modern Unixes, it actually doesn't create a complete copy. The two processes share the same address mappings until one or the other tries to write to memory. At that point the page it writes to is copied, the process attempting to write writes to one copy and the other process gets the other copy. Each page is only copied if and when it is written to by one process or the other.

As to why fork() and exec() are separate, there are a few cases where it's useful to use one without the other, or to have the child do something between fork() and exec().

P.S.: The issue was caused by a bug in the Cygwin DLL after all: http://cygwin.com/ml/cygwin-announce/20 ... 00041.html

P.P.S. I happened to mention that Cygwin now runs rebaseall automatically after each update.