posix-spawn is also only useful for fork+exec, where the new process starts executing a new binary. This is not the case in unicorn or resque, where the child processes actually need to be copies of the parent.
We're currently using posix-spawn in albino and grit, which execute external commands like `pygmentize` and `git`
Given that OSX's isn't dependent on page table size, I'm guessing it just always does copy-on-write... but that's a pretty un-knowledgeable guess.
There are ways to enable HugeTBL on linux to increase the page size, which can improve fork performance as well. See http://stackoverflow.com/questions/2731531/faster-forking-of..., http://linuxgazette.net/155/krishnakumar.html and http://sourceforge.net/projects/libhugetlbfs/
Does anyone know how fork is implemented on BSD/OSX and why it doesn't exhibit the same characteristics?
From version 2.6.38, Linux will get native huge page / superpage support too. http://lwn.net/Articles/423584/
I'd be shocked if it wasn't the same in linux.
If anyone's curious how processes/threads are represented internally on modern linux kernels, I wrote an article on that here: http://blog.andrewvc.com/fork2-is-dead-long-live-fork-i-mean...
