4 ms·
"What if we copied the entire address space of the program into a new process running from the same spot" This was actually the cause of 1-2 second blocks in o
by jorangreef 9y ago
"What if we copied the entire address space of the program into a new process running from the same spot"
This was actually the cause of 1-2 second blocks in our Node event loop. We were spawning a clamd scan asynchronously, from a process with several gigabytes of RSS. I never would have imagined that fork would blindly copy gigabytes of RSS every invocation. I should have known. It took a few months to track down.
The kicker is that Node calls fork from the main event loop thread and not from the thread pool, in order to hack around the GC, if I understand correctly.
See the relevant Node issue here:
https://github.com/nodejs/node/issues/14917 https://github.com/nodejs/node/issues/14917
- rkeene2 9y agofork() doesn't copy the blocks -- they're CoW -- but rather the time it takes is in setting up the CoW table. You can mitigate this if you tell clone(2) that the only thing you are going to do right after creating a new process is execve(2) so don't bother actually creating that. I see that mentioned at the end, but with the question of whether the setup is also combinable (it probably is).
- vram22 9y agoI'm not quite sure, but I think I remember reading that CoW (Copy on Write) was not there in the earliest Unixes. Might have been implemented at Berkeley some time later. Seem to remember reading this some years ago when reading about fork, because without CoW, fork's copying was expensive, particularly if you were going to exec another program in the child just after forking.
- mcguire 9y agoThat's technically what vfork() was intended for.