Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Properly serialize fork() operations
This change solves an issue where many threads attempting to spawn forks at once would cause fork() performance to degrade with the thread count. Things got real nasty on NetBSD, which slowed down the whole test fleet, because there's no vfork() and we're forced to use fork() in our server. threads count task 1 1062 fork+exit+wait 2 668 fork+exit+wait 4 66 fork+exit+wait 8 19 fork+exit+wait 16 22 fork+exit+wait 32 16 fork+exit+wait Things are now much less bad on NetBSD, but not great, since it does not have futexes; we rely on its semaphore file descriptors to do conditions threads count task 1 1085 fork+exit+wait 2 842 fork+exit+wait 4 532 fork+exit+wait 8 400 fork+exit+wait 16 276 fork+exit+wait 32 66 fork+exit+wait With OpenBSD which also lacks vfork(), things were just as bad as NetBSD threads count task 1 584 fork+exit+wait 2 687 fork+exit+wait 4 206 fork+exit+wait 8 24 fork+exit+wait 16 33 fork+exit+wait 32 26 fork+exit+wait But since OpenBSD has futexes fork() works terrifically thanks to *NSYNC threads count task 1 525 fork+exit+wait 2 580 fork+exit+wait 4 451 fork+exit+wait 8 479 fork+exit+wait 16 408 fork+exit+wait 32 373 fork+exit+wait This issue would most likely only manifest itself, when pthread_atfork() callers manage to slip a spin lock into the outermost position of fork's list of locks. Since fork() is very slow, a spin lock can be devastating Needless to say vfork() rules and anyone who says differently is kidding themselves. Look at what a FreeBSD 14.1 virtual machine with equal specs can do over the course of three hundred milliseconds. threads count task 1 2559 vfork+exit+wait 2 5389 vfork+exit+wait 4 34933 vfork+exit+wait 8 43273 vfork+exit+wait 16 49648 vfork+exit+wait 32 40247 vfork+exit+wait So it's a shame that so few OSes support vfork(). It creates an unsavory situation, where someone wanting to build a server that spawns processes would be better served to not use threads and favor a multiprocess model
- Loading branch information