Чи потоки копіюються під час виклику вилки?

Якщо у мене є програма, що працює з потоками і дзвонять fork()на систему на основі Unix, чи потоки скопійовані? Я знаю, що віртуальна пам'ять для поточного процесу копіюється 1: 1, щоб новий процес породився. Я знаю, що потоки мають власний стек у віртуальній пам'яті процесу. Таким чином, принаймні стопку ниток теж слід копіювати. Однак я не знаю, чи є щось більше для потоків, які не перебувають у віртуальній пам'яті і, таким чином, НЕ копіюються. Якщо цього немає, розділяють два процеси потоки або вони є незалежними копіями?

Ні.

Нитки не скопійовані fork(). Специфікація POSIX говорить (наголос - це моє):

fork - створити новий процес

Процес повинен бути створений однією ниткою . Якщо багатопотоковий процес викликає fork (), новий процес повинен містити репліку виклику потоку та всього його адресного простору, можливо, включаючи стани мутексів та інших ресурсів. Отже, щоб уникнути помилок, дочірній процес може виконувати лише безпечні для асинхронного сигналу операції до тих пір, поки не буде викликана одна з функцій exec.

Щоб обійти цю проблему, існує pthread_atfork()функція, яка допомагає.

чоловіча виделка :

Дочірній процес створюється однією ниткою - тією, що викликала fork (). Весь віртуальний адресний простір батька реплікується в дочірні, включаючи стани мутексів, змінних умов та інших об'єктів pthreads; використання pthread_atfork (3) може бути корисним для вирішення проблем, які це може спричинити.

Із специфікацій бази відкритої групи випуск 7, 2018 року вилки :

Процес повинен бути створений однією ниткою. Якщо багатопотоковий процес викликає fork () , новий процес повинен містити репліку виклику потоку та всього його адресного простору, можливо, включаючи стани мутексів та інших ресурсів. Отже, щоб уникнути помилок, дочірній процес може виконувати лише безпечні для асинхронного сигналу операції до тих пір, поки не буде викликана одна з функцій exec .

Коли програма викликає fork () від обробника сигналу та будь-якого з оброблювачів виделки, зареєстрованих pthread_atfork (), викликає функцію, яка не є безпечною для сигналу асинхронізації, поведінка не визначена.

Спочатку "вилка" була досягнута записом завдання на диск, а потім, а не читанням в іншій потоці (що було б зроблено, якщо поміняти завдання на інший), змінивши ідентифікатор завдання зображення, що зберігається в пам'яті, і продовжуючи з його виконанням (як нове завдання). Це була дуже проста модифікація основного механізму комутації завдань, де лише одне завдання займало б оперативну пам'ять за один раз.

Звичайно, по мірі того, як управління пам'яттю стало більш детальним, ця схема була модифікована відповідно до нового середовища.