fork() был трюком 1970-х, чтобы сбросить программу на диск — и Linux наконец-то пытается это перерасти

Тихая кампания ядра против fork()

Статья LWN (5 июня 2026) проходит по нескольким попыткам увести Linux от fork() + exec(). Патч «шаблона запуска» от Ли Чена — кэширование информации об исполняемом файле через spawn_template_create() / spawn_template_spawn() для повторных запусков — дал лишь около 2% и был фактически отвергнут. Предпочтительное направление — у Кристиана Браунера: создать пустой процесс через pidfd, а затем настроить его новыми декларативными syscall-ами в стиле pidfd_config() (по образцу fsconfig()), что позволит сделать нативный, внутри-ядерный posix_spawn().

Статья — чистый технический обзор. А тред — там, где живут история и продакшен-боль.

Почему fork() вообще существует (дело не в элегантности)

«это сделали так, чтобы можно было запустить программу, которая слишком велика, чтобы поместиться в память вместе с родительской программой. Исходная реализация работала, сбрасывая форкающуюся программу на диск при вызове fork()». — Джон Нэйгл (тот самый, из алгоритма Нэйгла)

Это переворачивает весь спор. fork() воспевают как красивый примитив; а начинался он как обходной приём для крошечной памяти.

Цена в продакшене: copy-on-write всё равно копирует таблицы страниц

«хотя fork() не копирует память, ему всё же надо скопировать таблицу страниц. Для процесса, удерживающего десятки ГБ ОЗУ, fork() может занять много времени … На m2.xlarge при ~25 ГБ ОЗУ fork() занял 5,67 секунды». — комментатор, ссылающийся на классический бенчмарк Redis

Copy-on-write избегает дублирования данных, но стоимость таблиц страниц масштабируется с объёмом отображённой памяти — вот почему «жирный» инстанс Redis может зависнуть на секунды при форке.

Но производительность — вообще ли правильный аргумент?

Коммиттер PostgreSQL предостерёг, что аргумент о скорости слабее, чем кажется:

«Любопытно, что самая широко используемая „большая“ ОС, которая не использует fork, то есть Windows, имеет дико медленное создание процессов … Согласен, что нужны примитивы без fork, просто не уверен, что производительность — лучший аргумент». — Андрес Фройнд, коммиттер PostgreSQL

Аргумент получше, отметил другой комментатор, — это дизайн: в мире без fork API просто принимали бы целевой pid и настраивали процесс снаружи — что в точности как работает Fuchsia и в точности туда, куда указывает набросок Браунера с pidfd-config. Дело против fork() не в том, что он медленный. А в том, что он всегда был остроумным ответом на проблему, которой у нас больше нет.