Сразу после того, как программа вызывает fork (), вновь созданный дочерний процесс идентичен (кучи, стек и даже файловые дескрипторы).Это фундаментальная часть того, как работает Unix;это то, как программа, запущенная вашей оболочкой, получает возможность записи в тот же терминал, что и оболочка.Программа не знает, в каком xterm она запускается;он просто наследует свои дескрипторы файлов stdin и stdout от своего родительского процесса.
Для памяти это может показаться бесполезной тратой, поскольку после fork () обычно выполняется exec () для запуска новой программы (опять же как в оболочке).Однако как дочерняя программа узнает, какую программу выполнять exec (), если у нее нет доступа к данным до точки fork ()?
Кроме того, fork () предшествует потокам и даже большеэлементарные формы многопроцессорной обработки, такие как select ().В прежние времена (при условии, что у вас было достаточно памяти) было обычным делом написать программу, которая с помощью fork () заставляла нескольких детей выполнять задачи, связанные с вводом-выводом.Если один дочерний процесс временно зависнет при выполнении операций ввода-вывода, другие все равно смогут двигаться дальше.Веб-сервер Apache работал в версии 1.x следующим образом.
Насколько работает механизм «копирования», это зависит от системы.Некоторые (более старые) системы реализуют это полное копирование, но большинство (более новых) систем реализуют его как копирование при записи.То есть в точке fork () родительский и дочерний элементы совместно используют одни и те же страницы памяти.Когда родительский или дочерний объект изменяет содержимое памяти, кто бы это ни сделал, он получает личную копию измененной памяти (изменения не передаются совместно);другой процесс сохраняет «старую» копию для себя.Если все, что они делают, это чтение, дополнительная память не используется.
Механизм копирования при записи полностью прозрачен для программы.Подсистема виртуальной памяти делает все это за кадром;даже адреса памяти не меняются.