Hacker News Reader

I'm curious what the applications are where this is an important optimization. Even for the very large Linux processes, it looks like 1/10sec per fork. On OSX, we're talking milliseconds. What sort of application is forking so often that this matters?

View on HN

If you use a basic process-per-connection model (select/fork/accept), 10 forks per second is not that much. The "classic Unix" Ruby HTTP servers like Unicorn do just that. (Apache 1.3 and at least one 2.x worker module also work this way, but Apache uses some tricks like preforking and recycling workers to make this fast - I'm not sure the Ruby servers do, too.)

Unicorn pre-forks workers upfront. New processes are not created per request.

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`

Yes, you're right, of course. Sorry.

On github.com, many types of requests can result in one or more calls to git commands. Every ms we can shave there can have a pretty big impact on response time.

Reply on news.ycombinator.com