[throwawaylinux]

> If you'd read the Microsoft Research PDF linked above, you'd have seen that fork scales with how much memory the parent is using, which would be invisible in these synthetic benchmarks.

Ah right, I was talking about SMP scaling, but yes fork does have an O(memory) scaling factor.

It certainly shows up on benchmarks because 99% of forking in Unix is on small processes (make, bash, etc.), not huge ones like Chrome. This kind of thing is why the Windows kernel is unable to compete with Linux in performance and scalability in in a lot of important basic operations that make things like git slow. The focus was on some academically supposedly "correct" interface or way of doing things, not what programs actually want to use.

> They say that Chrome on Linux might take up to 100ms to fork. That doesn't scream very fast to me.

Yeah probably true. If I needed a facility to be able to exec very frequently in a highly threaded application with a huge memory footprint and significant security concerns, I would almost certainly use a dedicated process to do that. You can potentially use posix spawn or clone directly, but forking from a thread from the main process in this case just seems unnecessary and asking for portability problems.

I don't say fork is perfect or can't be improved, but the hysteria about it's "infecting" the whole system and causing some vast problem is just not at all true.

[matheusmoreira]

> You can potentially use posix spawn or clone directly

You cannot use clone directly if you link to any libc.

[throwawaylinux]

You can if you are careful what you use libc for, of course you can't use most of its process management, threading, or make any reentrancy or thread safety assumptions.

I don't mean you would be likely use it if you were writing a normal application in C, but a special case like creating your own runtime where existing interfaces don't do exactly what you like. You wouldn't be using those things in libc anyway in that case.