3 ms·
This is not a bad strategy, especially because between the moment you fork() and the child calls exec(), you have a lot of memory regions shared in copy-on-wri
by xroche 10y ago
This is not a bad strategy, especially because between the moment you fork() and the child calls exec(), you have a lot of memory regions shared in copy-on-write (because it would be Too costly to actually duplicate the universelle). Which means that busy threads writing in memory in the parent area will trigger minor page faults, possibly impacting performances...
- ithkuil 10y agoyeah, that's why vfork has been introduced back in the days. See http://man7.org/linux/man-pages/man2/vfork.2.html http://man7.org/linux/man-pages/man2/vfork.2.html
- the_why_of_y 10y agoThe "historic description" in the man page you cite disagrees: vfork(2) was added before BSD had copy-on-write, so the memory was actually copied and vfork(2) is essentially a crude hack to avoid that. Unfortunately once copy-on-write was implemented, the crude hack was retained for backwards compatibility....