Смысл схемы создания процессов в UNIX

в винде то же самое закамуфлировали под один вызов

сначала копировать себя, а затем заменять образ памяти?

предложи способ лучше, при этом учти COW

во-первых, после fork не всегда выполняют exec, а во-вторых, никто там ничего не копирует (без надобности), читай про COW Copy-On-Write

COW - это когда для дочернего процесса создаётся свое адресное пространство только при попытке запили, я правильно понял? Я не понимаю сам смысл создания копии. Почёму нельзя сразу создать отдельный процесс и образ памяти для него?

В UNIX существует только один системный вызов для создания нового процесса — fork. Этот вызов создает точную копию вызывающего процесса. После выполнения системного вызова fork два процесса, родительский и дочерний, имеют единый образ памяти, единые строки описания конфигурации и одни и те же открытые файлы. И больше ничего. Обычно после этого дочерний процесс изменяет образ памяти и запускает новую программу, выполняя системный вызов execve или ему подобный. Например, когда пользователь набирает в оболочке команду sort, оболочка создает ответвляющийся дочерний процесс, в котором и выполняется команда sort. Смысл этого двухступенчатого процесса заключается в том, чтобы позволить дочернему процессу управлять его файловыми дескрипторами после разветвления, но перед выполнением execve с целью выполнения перенаправления стандартного ввода, стандартного вывода и стандартного вывода сообщений об ошибках.

В Windows все происходит иначе: одним вызовом функции Win32 CreateProcess создается процесс, и в него загружается нужная программа. У этого вызова имеется 10 параметров, включая выполняемую программу, параметры командной строки для этой программы, различные параметры безопасности, биты, управляющие наследованием открытых файлов, информацию о приоритетах, спецификацию окна, создаваемого для процесса (если оно используется), и указатель на структуру, в которой вызывающей программе будет возвращена информация о только что созданном процессе. В дополнение к функции CreateProcess в Win32 имеется около 100 других функций для управления процессами и их синхронизации, а также выполнения всего, что с этим связано.

Я вот сейчас читаю 4 издание книги Таненбаума. Перевод, надо сказать, очень дерьмовый.

Смысл этого двухступенчатого процесса заключается в том, чтобы позволить дочернему процессу управлять его файловыми дескрипторами после разветвления, но перед выполнением execve с целью выполнения перенаправления стандартного ввода, стандартного вывода и стандартного вывода сообщений об ошибках.

Я один не пойму смысл этого предложения?

Не, ну так-то есть vfork(), который ничего не копирует даже при записи (UB). Но вообще, пайпы, например, очень активно юзают вывод предыдущей программы. И вообще много сервисов, создающих треды-копии, веб сревера, например. Так что доступ сынка к виртуальной памяти родителя (хотябы даже ридонли) это таки вин.

Что непонятно? Дочь не открывает дескрипторы заново, а юзает родительские, экономит память и время.

Вот теперь понятно. А в книге черт знает что написано.

Фича в том, что exec() не всегда нужен, можно выполнять одну и ту же программу в нескольких процессах, причём дочерние процессы продолжают работу с момента возврата из fork(), с уже проинициализированными файловыми дескрипторами. В винде так не получится, дочернему процессу придётся выполнять программу от начала

Иногда делают fork без exec. Иногда делают exec без форк. Это более гибкое API.

Привет. В винде для создания процесса используется один системный вызов. В никсах же их два: fork а затем exec.

Один. exec не создаёт процессы.

ооп, наследование, полиморфизм, инкапсулция, унификация, KISS, DRY, YAGNI

паттерны проектирования, agile, scrum

Если точно, то, таки, два - fork и clone.

clone

CONFORMING TO
       clone() is Linux-specific and should not be used in programs intended to be portable.

posix_spawn() специально для тебя.

execve() is Posix-specific and should not be used in programs intended to be portable

/fat

Дочь не открывает дескрипторы заново, а юзает родительские, экономит память и время.

Вот теперь понятно.

fork-exec не был предназначен для экономии ресурсов (и в первые годы UNIX никакого COW не было). Создание процессов через fork - это способ настроить среду исполнения потомка (упрощенно говоря, заполнить данные в памяти и открыть/закрыть нужные дескрипторы).

«Функция из переносимого интерфейса не должна использоваться в программах, которые хотят быть переносимыми»? Ты совсем шизанулся?

fork-exec не был предназначен для экономии ресурсов (и в первые годы UNIX никакого COW не было).

пофикшено в Plan 9. там rfork имеет дополнительные поля (FreeBSD: тоже rfork) — можно указать какие именно ресурсы разделяются

Создание процессов через fork - это способ настроить среду исполнения потомка (упрощенно говоря, заполнить данные в памяти и открыть/закрыть нужные дескрипторы).

ну да. опять же, в Plan 9 можно указать какие ресурсы разделяются (включая пространства имён файловой системы). то есть, у каждого процесса точка зрения на файловую систему настраивается по-разному, клиент-сервер файловый выступает объектным клиентом и сервером, объекты представляются в качестве виртуальных псевдофайлов, P9 fs как файловый протокол реализует метаобъектный протокол, прозрачный по сети. сервер выступает мультиплексором реальных многих объектов/ресурсов/файлов в один виртуальный псевдофайл пространства имён, клиент — демультиплексором или пользователем виртуального ресурса. точка зрения на эти вирутальные псеводфайлы пространства имён — разная у клиента и сервера.

например: в оконной системе rio отдельные неразделяемые ресурсы «окна» /dev/window/NNN => «отображаются на» псеводфайл, общий разделяемый ресурс /dev/window текущего приложения. похоже и в текстовом редакторе/операционной среде/IDDE acme: контрольные файлы реализуют интерфейс доступа к ресурсам acme, окнам приложения.

точнее, не «интерфейс API» а протокол управления ресурсами, метаобъектный протокол . реализованный через файлы.

в этом смысле и REST-like API для управления ресурами Content-Addressable Memory тоже можно рассматривать не как набор микросервисов, а как метаобъектный протокол. как и P9FS тоже.

в Erlang взаимодействие между легковесными процессами реализовано как пролог, как марковский алгоритм. то есть: вместо действий-программ-процессов-алгоритмов, связанных через пайпы, простым текстовым интерфейсом (уникальным для каждой пары программ) или «объектным интерфейсом», недоуниверсальным метапротоколом (как в PowerShell: передаются между пайпами не текст, а объекты, у которых можно рефлексией опросить свойства, подёргать за стандартные методы) — Erlang ближе к базе ЗНАНИЙ, продукционной модели ЕСЛИ <событие>, ТО <действие> : если есть событие-вывод на стандартный вывод поставщика, то запустить действие-обработку события у потребителя.

при этом паттерн матчинг, подстановки в Erlang, plumbing в Plan9 делают механизм вызова более универсальным и удобным.

от сильносвязанных API к более слабосвязанным компонентам, агентам-объектам и протоколам.

fork-exec не был предназначен для экономии ресурсов (и в первые годы UNIX никакого COW не было).

пофикшено в Plan 9

Пофикшено в UNIX задолго до Plan9.

В остальном - вопрос был не о Plan9 и не об Erlang. И, внезапно, Plan9 мертв.

по сути, в Plan 9:

• файловый интерфейс доступа, прозрачный по сети(P9FS) к объектным серверам — мультиплексорам ресурсов
• универсальная шина сообщений в универсальном формате, напоминающем метаобъектный протокол
• диспетчеризация сообщений между процессами по правилам (шина plumber для обмена сообщений, пример правил в конце)
• микросервисы через контрольные файлы
• контрольные файлы как метаобъектный протокол взаимодействия сервисов
• файловый API : open/...read/write в контрольные файлы ... read/write в «ресурсы»/close как метаобъектный протокол управления ресурсами, поддержка жизненного цикла ресурсов

получаются более composable архитектура, позволяющая более просто выполнять оркестрацию сервисов

в Octopus (тут, Plan B, Op, the Box Protocol — cм. публикации на тему Smart Spaces

есть очередные подвижки в этом направлении.

в Plan 9 можно говорить про настраиваемый rfork как элемент архитектуры. потому что разделяемых библиотек нет, а разделяемые ресурсы — есть

Да, сейчас говорят, что fork/exec - более гибко, и лучше предоставить самому процессу возможность сделать с файловыми дескрипторами то, что что он хочет, чем создавать единый системный вызов с 10 параметрами (как CreateProcess)... Но на самом деле, причина, скорее всего, в другом.
Есть статья Дениса Ритчи, в которой он рассказывает, что fork/exec - одно из тех решений, которое было сделано потому, что тупо требовало меньших усилий по кодированию на определенном этапе развития Unix.
Это было еще в те времена, когда Unix пешком ходил под стол, и не существовало ни fork, ни exec, и то, что сейчас делает exec, делалось самим шеллом (sh). И не было смысла дублировать этот код в новом системном вызове для создания процесса, а все, что было нужно сделать тогда - это добавить fork(), что и заняло всего 27 строчек =)

http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf