ELelvinyung·Feb 1, 2017
I'm not sure that this experiment is meaningful.
The point of a preload-fork process model à la Unicorn is that the `fork` syscall gives you copy-on-write[1] shared memory between the parent and the child, so you save a bunch of time because you get to use the same piece of memory, and you save a bunch of space because you get to use the same piece of memory. In those cases, disabling GC and killing workers made sense because you could start another one up literally instantly, with basically zero cost in time or space.
`fork` in Node.js[2] isn't a real `fork` in the syscall sense. Node.js's `fork` is more-or-less a misnomer; it doesn't use the `fork` syscall at all. It basically starts up a completely new process, and opens an IPC pipe between the parent and the child. There's none of the CoW memory sharing that you get from the syscall `
Read the rest
fork`, and you incur all of the cost of loading stuff the normal way.
As of 2011, there were no plans to support a real `fork` in Node.js.[3] This seems to still hold true.
1: https://linux.die.net/man/2/fork
2: https://nodejs.org/api/child_process.html#child_process_chil...
3: https://github.com/nodejs/node-v0.x-archive/issues/2334#issu...