3 ms·
> Of course, fork() is not especially fast fork itself is pretty fast, relatively speaking (unless you have a large virtual address space and 4K pages or simil
by sebcat 9y ago
> Of course, fork() is not especially fast
fork itself is pretty fast, relatively speaking (unless you have a large virtual address space and 4K pages or similar). fork+execve+process-runtime-initialization is much slower.
On my X201 (anno 2010), with 10000 iterations, sequential fork+exit(0)-in-child+wait takes:
$ /usr/bin/time ./forkfest
2,49 real 0,38 user 2,19 sys
while sequential fork+execve("/usr/bin/true",...)-in-child+wait takes:
$ /usr/bin/time ./forkfest2
10,99 real 3,10 user 7,94 sys
EDIT: also, My X201 is clocked at 1199 MHz (50%) for power saving reasons
- matthewaveryusa 9y agoYes it's slower compared to a single multithreaded evented server, but that fork gives you process separation which is a huge security feature and resilient to one bad request taking down your whole server. You can aslo write your code blocking + single thread which is so simple and easy to debug
- dfox 9y agoOn paged systems fork() is usually reasonably fast, but for CGI you do fork()+exec() and while exec() is also reasonably fast, the stuff that the happens in child process between it's start and entry into main() (ie. dynamic linking, libc initialization) is somewhat on the slower side. (Not to mention interpreter startup for interpreted languages)
- jimbokun 9y agoThis seems to reinforce the brilliance of the Erlang VM. Basically, make "fork" super super cheap. Full process isolation, "let it crash" error handling, and lots of other benefits.