Hacker News Reader

Comment by malkia | Hacker News Reader

Wondering how well fork() works?

I was wondering the same thing. The features page claims "copy on write fork implementation" but that is not universally true. A cursory look at the code suggests that every allocation is a Win32 file mapping object (aka NT section) underneath, which the fork worker (mm_fork) remaps into the forked process. This means the memory is shared between two processes, and not in a CoW fashion. A write to the memory region from the forked process will be visible in the parent. These are not correct semantics for fork.

I am hoping I misread the code and someone can prove me wrong here, because it looks like a cool project with a lot of potential.

From little I've read on cygwin mailing list (btw, cool folks over there) - it seems the problem is not very easy. If I'm not mistaken the Windows Kernel actually does support fork()-ing, but the win32k system somehow "forbids" it (lots of grains of salt). After all for a long time there was a commercial UNIX compatible offering on Windows that probably used fork() all over and must've worked (also it supported case-sensitive names for the filesystem)

BTW, the coolest usage of fork(), and granted a pain in the ass to port possibly was the one in REDIS where antirez used it to fork() at certain time the current process, then write back the state of memory knowing that it'll get a "snapshot" of it, and if writes to disk succeed, this "snapshot" would correctly and fully be written to the disk.

I know there are plenty of other uses (for example this way "lua" can do threads with just a bit of a communication library on top... e.g. any language without explicit thread handling can actually use them).

Wondering what made win32k folks disable it. Possibly there are lots of gotchas...

Using fork to get a "snapshot" of memory seems... like a roundabout way of doing things. The underlying memory mapping mechanism should expose a simple way of just doing it directly. (I still don't understand the point of fork, especially when most of the time exec is just gonna overwrite things anyways. And the impact fork has is to massively increase potentially used memory, leading to the dumb memory overcommit semantics and hack fixes like OOM killer.)

Yup. indeed, but it seems so elegant, in the same way (elegant) as one can implement undo using closures - at the expense of unaccounted resources (cpu, memory, who knows what else).

From redis's page: http://redis.io/topics/persistence

"RDB needs to fork() often in order to persist on disk using a child process. Fork() can be time consuming if the dataset is big, and may result in Redis to stop serving clients for some millisecond or even for one second if the dataset is very big and the CPU performance not great. AOF also needs to fork() but you can tune how often you want to rewrite your logs without any trade-off on durability"

Reply on news.ycombinator.com