iZEN купите себе iPHONE

>Да, я в курсе этого высказывания в манах Linux'а.

Ну что ты прицепился к vfork? vfork (как уже выше процитировал tailgunner) --- это не более чем быстрая запускалка для других программ, которая избегает ненужного копирования адресного пространства родительского процесса, поскольку ребенок потом сразу же делает exec. И fork она никак не заменит, поскольку он используется не только в комбинации fork&exec.

А clone это никакой не костыль (как раз vfork --- это и есть костыль),это продвинутый fork в котором явно можно указать, что ребенок должен разделять с родителем.

все ссылки в исходниках

>>Есть здесь спецы по FreeBSD - там и сейчас vfork == fork?

> Они друг друга не заменяют. Во FreeBSD до сих пор это два отдельных вызова.

Я бы все-таки предпочел услышать мнение спеца по FreeBSD.

http://www.engr.colostate.edu/~dilumb/Documents/CS204/05-Process-Windows_Linu...

>ну зачем же, можно и в библиотечку оформить

при наличии стандартной функции из POSIX? Ноу комментс :)

>префорк N процессов + механизм балансировки по форкам; где N - кол-во ядер|процессоров

Посмотри на QtConcurrent. И зацени сложность твоего решения с тем, что там есть. Приложения бывают не только web-серверами и поисковыми машинами, ага :)

iZEN, давайте Вы не будете позориться :-)

Вот кусок vfork(2) из FreeBSD 7.X:

BUGS
This system call will be eliminated when proper system sharing mechanisms
are implemented. Users should not depend on the memory sharing semantics
of vfork() as it will, in that case, be made synonymous to fork(2).

To avoid a possible deadlock situation, processes that are children in
the middle of a vfork() are never sent SIGTTOU or SIGTTIN signals;
rather, output or ioctl(2) calls are allowed and input attempts result in
an end-of-file indication.

Так что vfork теперь считается устаревшим и является синонимом fork().

>Предлагаю ... ЛОРовские треды отныне называть не иначе, как трендами. Лучше "трынды", от слова "трындеть"

эх... вчера хотел сабж запостить...

man 2 vfork

BUGS 

This system call will be eliminated when proper system sharing mechanisms
are implemented. Users should not depend on the memory sharing semantics
of vfork() as it will, in that case, be made synonymous to fork(2).

To avoid a possible deadlock situation, processes that are children in
the middle of a vfork() are never sent SIGTTOU or SIGTTIN signals;
rather, output or ioctl(2) calls are allowed and input attempts result in
an end-of-file indication. 


>Так что vfork теперь считается устаревшим и является синонимом fork().

Читай внимательнее! В каком случае vfork(2) может рассматриваться синонимом fork(2), а в каком нет.
Про "устаревание" vfork(2) в man'е ни слова. Учи английский, неуч.

>>Так что vfork теперь считается устаревшим и является синонимом fork().

>Читай внимательнее! В каком случае vfork(2) может рассматриваться синонимом fork(2), а в каком нет.

Вот же упрямый тролль попался :)

"This system call will be eliminated when proper system sharing mechanisms are implemented. Users should not depend on the memory sharing semantics of vfork() as it will, in that case, be made synonymous to fork(2).

FreeBSD 7.0 June 4, 1993"

Ты способен перевести фразу "Users should not depend on the memory sharing semantics of vfork()"? vfork - точное подмножество fork, и если заменить vfork на fork, все корректные программы продолжат работать.

> Про "устаревание" vfork(2) в man'е ни слова. Учи английский, неуч.

Зато есть слова про то, что когда будет реализованы "proper system sharing mechanisms", vfork заменят на fork. Ты хочешь сказать, что эти механизмы не реализованы за почти 16 лет? :D

>Про "устаревание" vfork(2) в man'е ни слова.

>>BUGS

>>This system call will be eliminated when proper system sharing mechanisms are implemented.

О да, конечно. Это, верно, наоборот, развитие, да?

>Учи английский, неуч.

Да уж куда ему до тебя...

>А clone это никакой не костыль (как раз vfork --- это и есть костыль),это продвинутый fork в котором явно можно указать, что ребенок должен разделять с родителем.

Ещё раз для вендузятников оформлю своё мнение.
clone(2) — это изобретение создателей ядра Linux 2.4. Больше нигде, ни в POSIX-стандартах, ни в SVR4, ни в современных версиях Solaris такого вызова нет.

" История

В версиях Linux до 2.6 не существовало реальной потоковой архитектуры, хотя поддерживался, например, системный вызов clone(), создававший копию вызвавшего его процесса в том же адресном пространстве памяти, что и сам процесс. В частности, проект LinuxThreads использовал этот системный вызов для организации поддержки потоков в рамках одного адресного пространства. К сожалению, эта библиотека имела проблемы с совместимостью со стандартом POSIX, в том числе по обработке сигналов реального времени, диспетчернизации и межпроцессных синхронизирующих примитивов.

Для исправления ситуации были начаты два проекта — NGPT (Next Generation POSIX Threads, Потоки POSIX следующего поколения), разрабатывавшийся в том числе разработчиками IBM и NPTL, разрабатываемого сотрудниками Red Hat. NGPT был закрыт в середине 2003, спустя некоторое время после выпуска NPTL.

NPTL имеет некоторые сходства с LinuxThreads, такие как первичная абстракция ядра тоже процесс или новые потоки создаются вызовом clone(). NPTL требует особого модуля ядра, поддерживает фьютексы (futex).

NPTL включена в дистрибутив Red Hat Enterprise Linux с версии 3, и является частью glibc.
"
http://dic.academic.ru/dic.nsf/ruwiki/176273

Уймись уж наконец. Костыль он и есть костыль, приделанный ПОСЛЕ того, как архитектура ядра сформировалась. Далее облагораживание инвалидного ядра Linux велось на средства сторонних организаций.

> clone(2) — это изобретение создателей ядра Linux 2.4

2.0

> Больше нигде, ни в POSIX-стандартах, ни в SVR4, ни в современных версиях Solaris такого вызова нет.

man 2 rfork на FreeBSD, юзеров которой ты успешно позоришь :)

> Далее облагораживание инвалидного ядра Linux велось на средства сторонних организаций.

Ты завидуешь штоле? :D

>>This system call will be eliminated when proper system sharing mechanisms are implemented.

>О да, конечно. Это, верно, наоборот, развитие, да?

Это остановка в развитии многопоточности порождаемых процессов на уровне ядра, только и всего.

Многопоточность в современных системах FreeBSD реализуется легковесными потоками уровня пользователя (pthreads) M:N (libkse в старых версиях FreeBSD 6.x) или 1:1 (libthr в FreeBSD 7.1) на основе POSIX-стандартов.

В Linux многопоточность реализуется в ядре, по сути своей работы — LWP (код NPTL), как в Windows, и с использованием костылей типа clone(2).

>man 2 rfork на FreeBSD, юзеров которой ты успешно позоришь :) 
BUGS
     FreeBSD does not yet implement a native clone() library call, and the
     current pthreads implementation does not use rfork() with RFMEM.  A
     native port of the linux threads library, /usr/ports/devel/linuxthreads,
     contains a working clone() call that utilizes RFMEM.  The rfork_thread(3)
     function can often be used instead of clone().

HISTORY
     The rfork() function first appeared in Plan9.

Plan9 создавали линуксойды?

> Уймись уж наконец. Костыль он и есть костыль, приделанный ПОСЛЕ того, как архитектура ядра сформировалась. Далее облагораживание инвалидного ядра Linux велось на средства сторонних организаций.

1. Рекомендую побольше уважения. 2. Вызов clone(2) появился как минимум в linux 2.0 3. Архитектура ядра Linux не является "окаменевшей", она меняется постоянно, даже в рамках ядра 2.6.

Может кому-то и интересно твоё показное невежество читать, но мне уже надоело.

>> треды не нужны!!!11 всем осиливать FSM!!!11

> Аббревиатура FSM у мя ассоциируется с "конечный распознающий автомат"

Так о нём же и речь.

> Многопоточность в современных системах FreeBSD реализуется легковесными потоками уровня пользователя (pthreads) M:N (libkse в старых версиях FreeBSD 6.x) или 1:1 (libthr в FreeBSD 7.1) на основе POSIX-стандартов.

Не представляю что может означать "реализуется ... на основе POSIX-стандартов" -- в стандартах уже есть какая-то готовая реализация, которую надо просто адаптировать? Стандартам обычно соответствуют, если они просто описание API.

Обобщённую модель M:N пытались сделать уже много раз, каждый раз всё заканчивалось тем, что невозможно до конца её корректно реализовать и по производительности 1:1 часто не хуже, а то и лучше. Для определённости, рассмотри случай когда M=1. Получается 1:N и если один из N потоков полезет к файловой системе, то будет не очень приятная блокировка остальных N-1, которую никто не ждёт. Про сигналы тоже молчу.

> Многопоточность в современных системах FreeBSD реализуется легковесными потоками уровня пользователя (pthreads) M:N (libkse в старых версиях FreeBSD 6.x) или 1:1 (libthr в FreeBSD 7.1) на основе POSIX-стандартов.

> В Linux многопоточность реализуется в ядре, по сути своей работы — LWP (код NPTL), как в Windows, и с использованием костылей типа clone(2).

Аааа, держите меня трое %) Если ты еще не знаешь, то и модель M:N, и модель 1:1 _требуют_ поддержки LWP в ядре. Так что во FreeBSD она тоже есть ;)

> Plan9 создавали линуксойды?

То тебе не нравится, что Линукс изобрел "костыль" под названием clone(2), то тебе не нравится, что clone(2) сделан под влиянием Plan9 (и этого влияния никто не отрицал).

И как насчет факта, что в "чистом Unix" FreeBSD есть полный функциональный аналог clone(2)? Становится ли FreeBSD инвалидом на костылях?

>> Аббревиатура FSM у мя ассоциируется с "конечный распознающий автомат"

> Так о нём же и речь.

Finite State Machine. Это в русской терминологии кажется просто "конечный автомат", забыл уже когда добавляется "детерминированный", а когда "недетерминированный" :)

> Если ты еще не знаешь, то и модель M:N, и модель 1:1 _требуют_ поддержки LWP в ядре.

На ум приходят mit-threads и green-threads. Не знаю почему :)

iZEN, что ты так к clone() придолбался?

vfork() и fork() в Linux есть. vfork() - вызов clone() c флагами CLONE_VM и CLONE_VFORK - нормальный vfork(). Скорость fork() обеспечивается с помощью CopyOnWrite.

В итоге: имеем быстрые fork() и vfork(), а кроме того опциональный clone() к кучей вкусных флагов. Функциональность как бы на высоте и не в ущерб скорости.

Тебе не нравится, что clone() нет в POSIX? Так один из базовых принципов Unix Way: Если для прогресса фишка требуется - то это повод пересмотреть стандарт, а не прогибаться под устаревшее решение.

>> Если ты еще не знаешь, то и модель M:N, и модель 1:1 _требуют_ поддержки LWP в ядре.

>На ум приходят mit-threads и green-threads. Не знаю почему :)

Это 1:N, о них речи пока не было :)

>> Больше нигде, ни в POSIX-стандартах, ни в SVR4, ни в современных версиях Solaris такого вызова нет.

>man 2 rfork на FreeBSD, юзеров которой ты успешно позоришь :)

Да вот незадача, rfork(2) из FreeBSD не использует clone(2). :))

Зато clone(2) в Linux как комбайн_на_все_руки_мастер совмещает все известные инструменты создания новых процессов и потоков в ядре, но это у него получается как у лягушки-амфибии: плавает недалеко и не быстро, летает плохо, по суше передвигается скача на задних лапах, быстро устаёт. Поэтому пришлось изобрести NPTL.

>> Далее облагораживание инвалидного ядра Linux велось на средства сторонних организаций.

> Ты завидуешь штоле? :D

Да не особо. У этих организаций получается собственные "карманные линуксы", хоть код и открыт. Опять как всегда: кучка кода для реализации многозадачности на десктопах, кучка кода для реализации многозадачности на суперкомпьютерах, причём одно на другое как-то не влияет даже (костыль здесь — костыль там).

>>> Если ты еще не знаешь, то и модель M:N, и модель 1:1 _требуют_ поддержки LWP в ядре.

>>На ум приходят mit-threads и green-threads. Не знаю почему :)

>Это 1:N, о них речи пока не было :)

При M=1? :)

> Да вот незадача, rfork(2) из FreeBSD не использует clone(2). :))

Не-а. Незадача в том, что ты сказал: "Больше нигде, ни в POSIX-стандартах, ни в SVR4, ни в современных версиях Solaris такого вызова нет". Не стоит тебе рассуждать о том, чего не знаешь :)

> Зато clone(2) в Linux как комбайн_на_все_руки_мастер совмещает все известные инструменты создания новых процессов и потоков в ядре, но это у него получается как у лягушки-амфибии: плавает недалеко и не быстро, летает плохо, по суше передвигается скача на задних лапах, быстро устаёт

То, что ты не знаешь, какие проблемы решал NPTL, тоже понятно :) Hint: только небольшая их часть была связана с clone(2).

А главное - все они уже решены. Давно. К текущему состоянию clone(2) у тебя претензии есть? :D

> кучка кода для реализации многозадачности на десктопах, кучка кода для реализации многозадачности на суперкомпьютерах, причём одно на другое как-то не влияет даже (костыль здесь — костыль там).

Список кучек кода и костылей - в студию!

>> Это 1:N, о них речи пока не было :)

> При M=1? :)

Ну это ты их упомянул зачем-то... кстати, ЕМНИП, во FreeBSD блокирующиеся системные вызовы не блокировали userspace-нити - делался upcall из ядра в userspace-планировщик, и он выбирал другую нить.

>Скорость fork() обеспечивается с помощью CopyOnWrite.

Вот уж открытие для себя сделал. Во FreeBSD, по крайней мере с 5-й ветки, так же.

А заслуга использования этого системного вызова знаешь кого? Товарищей учёных из университета имени Беркли. Впервые идея создания процесса с помощью одного системного вызова fork была реализована в операционной системе GENIE (SDS-940).

>И как насчет факта, что в "чистом Unix" FreeBSD есть полный функциональный аналог clone(2)? Становится ли FreeBSD инвалидом на костылях?

Какой аналог? В ядре FreeBSD нету LWP, для которых он мог бы понадобиться.
rfork(2) FreeBSD не умеет clone(2). Для эмуляции его поведения приходится устанавливать порт /usr/ports/devel/linuxthreads.

Читай внимательно мои сообщения по ходу всей темы, чтобы лишний раз не переспрашивать.

> А заслуга использования этого системного вызова знаешь кого? Товарищей учёных из университета имени Беркли.

Стало уже скучно. Аргументы то будут, кроме общего словоблудия? Ну там бенчмарки какие, список не реализованных POSIX функций или релизованных не так как надо из-за "врождённой кривости". Т.е. список _реальных_ проблем есть? Или единственная реальная проблема у тебя в голове?

>clone(2) — это изобретение создателей ядра Linux 2.4. Больше нигде, ни в POSIX-стандартах, ни в SVR4, ни в современных версиях Solaris такого вызова нет.

Курим man 2 clone, в коем даже аглицкий уже разуметь не нужно:

"Данная страница руководства соответствует ядрам 2.0.x, 2.1.x, 2.2.x, 2.4.x, а также glibc 2.0.x и 2.1.x."

Так что про 2.4 - из области художественного свиста, clone появился раньше.

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

>Уймись уж наконец. Костыль он и есть костыль, приделанный ПОСЛЕ того, как архитектура ядра сформировалась.

Архитектура линуксового ядра не сформировалась и не сформируется никогда, читайте высказывания товарища Торвальдса. С ярлыком "костыль" вы погорячились, в манах по клону и близко нет фраз типа: "This system call will be eliminated when proper system sharing mechanisms are implemented." Из этого заключаем, что vfork как раз костыль, т.е. временная уродливая мера призванная преодолеть несовершенство существующей реализации, которую уберут как только в нем отпадет необходимость.

> rfork(2) FreeBSD не умеет clone(2)

Ааааа, держите меня четверо %) "FreeBSD does not yet implement a native clone() library call" - ты system call от library call отличаешь? "A native port of the linux threads library, /usr/ports/devel/linuxthreads, contains a working clone() call that utilizes RFMEM." Так что _ядро_ FreeBSD содержит clone(2), только он называется по-другому. То, что в libc его нет, ничего не меняет - в ядре есть весь необходимый код.

>Не стоит тебе рассуждать о том, чего не знаешь :)

Сообщи, пожалуйста, где ещё кроме Linux Kernel 2.0-2.4 реализован системный вызов clone(2).

>К текущему состоянию clone(2) у тебя претензии есть? :D

Да. Для его эмуляции на FreeBSD нужно устанавливать отдельный порт. Лишняя сущность.

>Список кучек кода и костылей - в студию!

Сама концепция [LWP в ядре] == всё равно что запускать одну виртуальную машину поверх другой: эффект WOW есть, а смысла никакого. Ничего нового в Подлунном мире LWP'шники не изобрели. Надо оставаться на концепции [процесс + пользовательские легковесные потоки], стараясь свести к минимуму накладные расходы на шедулинг легковесных потоков в пространстве пользователя — что и было сделано при переходе от FreeBSD 6.0 к FreeBSD 7.1: libkse (N:M) была заменена на libthr (1:1). Что положительно сказалось на тестах баз данных и bind FreeBSD 7 vs. Linux 2.6.

когда аргументы кончаются, нужно цепляться к словам

Держите его четверо, да покрепче! Психиатров сюда.

>> Не стоит тебе рассуждать о том, чего не знаешь :)

> Сообщи, пожалуйста, где ещё кроме Linux Kernel 2.0-2.4 реализован системный вызов clone(2).

Сообщаю: часть функциональности линуксового системного вызова, необходимая для работы с нитями, clone(2) во FreeBSD реализуется системным вызовом rfork(2). См. частности флаги RFTHREAD, RFMEM, RFSIGSHARE и RFLINUXTHPN (для эмуляции старого Линукса).

>>К текущему состоянию clone(2) у тебя претензии есть? :D

>Да. Для его эмуляции на FreeBSD нужно устанавливать отдельный порт. Лишняя сущность.

Ахренеть претензия к _линуксовому_ системному вызову %)

>>Список кучек кода и костылей - в студию!

>Сама концепция [LWP в ядре] == всё равно что запускать одну виртуальную машину поверх другой: эффект WOW есть, а смысла никакого. Ничего нового в Подлунном мире LWP'шники не изобрели. Надо оставаться на концепции [процесс + пользовательские легковесные потоки]

Пошел откровенный бред :D

> RTFM - тред и процесс в Линуксе весят одинаково. Более того они оба очень легкие

легкие ? тогда каким образом сабжевый тред создается в 600 раз быстрее и в 135 раз быстрее переключается контекст ? это числа с сайта сабжа. 2.5 порядка это нефиговая прибавка к пенсии.

Соревнование костыляторов

fork как и vfork суть unixовый костыль. дайте людям уже нормальный bugogaexec(2):

int bugogaexec(const int argc, const char * argv[]) RETURN VALUE: -1 if call failed, and errno is set to appropriate value or pid of new process

clone - тот же костыль, только вид с боку. то же самое перелопачивание таблиц адресации, удаление бита R - если. ничего нового.

ЗЫ: это есть в винде.

ЗЫ2: 2 байта на поток? я чего то не понимаю, но этого не может быть потому что этого не может быть. контекст на x86-32 составляет в минимуме 548 байт.

а вот и фиг вам.

ядро вообще не должно знать про потоки. у него должон быть процесс, который выставляет ядру заявку о том, какие процессоры и сколко он готов использовать. ядро же вызывает некий entry point, который загружает контекст, а потом по отключению процесса от процессора ядро сохраняет контекст. из плюсов - в ядре нафиг не нужно становится хранить лишние данные, и кучу task_struct.

из минусов - для этого придётся переписать весь линупс. как впрочем и фрю.

> а вот и фиг вам.

Выражайся яснее.

> ядро вообще не должно знать про потоки. у него должон быть процесс, который выставляет ядру заявку о том, какие процессоры и сколко он готов использовать. ядро же вызывает некий entry point, который загружает контекст, а потом по отключению процесса от процессора ядро сохраняет контекст

Поздравляю, ты изобрел KSE. Фря как раз от них отказалась недавно.

ну, через Ж писать им никто не запрещал.

Заметь, что "всю Фрю" им переписывать не пришлось.

> ну, через Ж писать им никто не запрещал.

Сделай лучше.

>Сообщаю: часть функциональности линуксового системного вызова, необходимая для работы с нитями, clone(2) во FreeBSD реализуется системным вызовом rfork(2). См. частности флаги RFTHREAD, RFMEM, RFSIGSHARE и RFLINUXTHPN (для эмуляции старого Линукса).

Ты различаешь понятие "часть" и "целое"? Между прочим, эти понятия из диалектического материализма, а не фрейдистской метафизики.

Дальше претензия моя вот в чём состоит, посмотри на дату изобретения rfork(2) и дату изобретения clone(2) и найди в этом диалектическое вытекание причины из следствия — какой инструмент у какого инструмента перенял нужные ему функции. И ответь сам на вопрос "Почему это было нужно делать в Linux?!", на который я пять часов назад тебе/всем заинтересованным анонимусам/ ответил.

>fork как и vfork суть unixовый костыль. дайте людям уже нормальный bugogaexec(2):
>int bugogaexec(const int argc, const char * argv[]) RETURN VALUE: -1 if call failed, and errno is set to appropriate value or pid of new process

>clone - тот же костыль, только вид с боку. то же самое перелопачивание таблиц адресации, удаление бита R - если. ничего нового.

Вот. Умный мальчик. Всё понял сам и расставил для себя приоритеты.

>ЗЫ: это есть в винде.

Ну так... :) Linux эмулирует не только Unix.

>> Сообщаю: часть функциональности линуксового системного вызова, необходимая для работы с нитями, clone(2) во FreeBSD реализуется системным вызовом rfork(2). См. частности флаги RFTHREAD, RFMEM, RFSIGSHARE и RFLINUXTHPN (для эмуляции старого Линукса).

> Ты различаешь понятие "часть" и "целое"?

Различаю. А ты различаешь, какую функциональность clone(2) rfork _не_ реализует? Объясни.

> посмотри на дату изобретения rfork(2) и дату изобретения clone(2) и найди в этом диалектическое вытекание причины из следствия — какой инструмент у какого инструмента перенял нужные ему функции.

На этот вопрос я уже десять раз ответил - rfork был раньше (реализован в Plan9), clone перенял из rfork.

> И ответь сам на вопрос "Почему это было нужно делать в Linux?!",

Потому что это элегантное техническое решение, доказавшее свою работоспособность в Plan9. Проще говоря, чтобы не изобретать велосипед с квадратными колесами вроде KSE во FreeBSD.

> на который я пять часов назад тебе/всем заинтересованным анонимусам/ ответил.

Ты за пять часов не привоел вообще никаких фактов о туманно описанных (тобою же) недостатках clone(2) в Linux.

>В *BSD другой, отличный от System V, принцип порождения процесса потомка: системный вызов vfork (спайка fork+exec) не копирует структуры процесса родителя и карты адресации, а приостанавливает процесс родителя и просто копирует регистры его карты адресации, далее запускает процесс-потомок и ждёт его окончания для возвращения управления в процесс родителя. Из-за того, что процесс родителя предоставляет своё адресное пространство процессу-потомку, вызов vfork выполняется гораздо быстрее тормознутых fork и exec в System V. Из-за отсутствия формальной защиты памяти процесса родителя, некоторые утилиты (csh, например) используют эту фичу.

в Linux тоже есть системный вызов vfork. Так что изыди, тролль.

// К.О.

потому что там были вполне себе bound потоки. осей без ядерного продолжения узерных потоков я пока не видел.

> осей без ядерного продолжения узерных потоков я пока не видел.

А я не вижу профита от такого. Впрочем, напишешь свою ОС - запости линк на ЛОР.

Если мне не изменяет склероз, iZENa по этому же поводу не так давно пинали ногами на опенке 8)) Впрочем, где его только не пинали... 8))

>Ты за пять часов не привоел вообще никаких фактов о туманно описанных (тобою же) недостатках clone(2) в Linux.

На: http://www.linux.org.ru/jump-message.jsp?msgid=3424009&cid=3425707
перевари ещё раз.

rfork(2) стал использоваться в FreeBSD с января 1996 года.
clone(2) стал использоваться в ядре Linux с июня 1996 года.

То, что он clone(2) перенял из rfork(2) какие-то концепции быстрого порождения дочерних процессов, не значит, что он стал вершиной программистской мысли. В 1996 году не было более удачной модели использования fork/vfork/rfork, но линуксойды пошли своим путём решили (за всех) объединить "всё в одном флаконе" — так появился виндоподобный комбайн clone(2). Напомню, на тот момент (1996г) решалась задача реализации многопроцессорности в ядре Linux и clone(2) позволял объединить все разрозненные вызовы порождения процессов в один вызов.

Что в итоге
С разработкой библиотеки NPTL в Linux 2.6 (декабрь, 2003г) надобность в услугах комбайнёрского вызова clone(2) исчезла. Так как NPTL решала задачи порождения и шедулинга легковесных потоков (LWP M:N) во всей ветке System V, включая дальнейшее её развитие в лице новых ядер Linux и Solaris!!!

Конечно после этого чиста-линуксовый clone(2) объявили ненужным комбайном. Но выбросить его из ядра Linux НЕЛЬЗЯ, потому что clone(2) реализует якобы "костыль" — функцию системного вызова Plan9 rfork(2), принятую в большом Unix. Вот так: rfork(2) нужен, но всё остальное из clone(2) не нужно. Так и тянется из кода в код ядра Linux этот комбайн.