>в Linux тоже есть системный вызов vfork.

Через параметр CLONE_VFORK системного вызова clone(2), дружочек.

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

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

А в Plan9 - с конца 80-х, и что?

> То, что он clone(2) перенял из rfork(2) какие-то концепции быстрого порождения дочерних процессов, не значит, что он стал вершиной программистской мысли.

Никто, кроме тебя, не присваивал clone(2) титул "вершины программистской мысли".

> В 1996 году не было более удачной модели использования fork/vfork/rfork

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

> линуксойды пошли своим путём решили (за всех) объединить "всё в одном флаконе"

В FreeBSD rfork появился раньше, умеет то же, что и линуксовый clone(2) - и при этом "линуксоиды решили"? И при этом "никаких аналогов clone в других Unix/POSIX-ядрах нет"?

> NPTL решала задачи порождения и шедулинга легковесных потоков (LWP M:N) во всей ветке System V

Какой еще M:N, NPTL реализует 1:1. Какая еще System V, NPTL специфична для Linux.

> С разработкой библиотеки NPTL в Linux 2.6 (декабрь, 2003г) надобность в услугах комбайнёрского вызова clone(2) исчезла.

Ыыыыы... всё с тобой окончательно ясно. NPTL использует clone(2), причем для NPTL туда был добавлен еще один флаг. Но зачем тебе это знать? Это же лишняя нагрузка для твоей read-only памяти, в которую на заводе прикола ради записали фразу "FreeBSD rulezz".

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

Ты сам-то ее читал? Впрочем, можешь не отвечать.

>int bugogaexec(const int argc, const char * argv[])

Клево, чем это отличается от fork exec? Ну да, вопрос глупый, тыж нихрена в линуксах не петришь. Прежде чем трындеть почитай ман по клону, нет в твоей мастдайке его нет, если на гугле не забанили так и набирай "man clone" без кавычек, на всякий случай.

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

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

"The best known implementation of protothreads (by Adam Dunkels) uses just two bytes per protothread. This implementation is not quite so parsimonious (mainly because this implementation includes a scheduler: threads are on either the wait or run list); our environment is not as memory-constrained."

A-234, не ведись на скучных троллей, не мешай читать iZEN'а.

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

Чего сказал, сам понял? Ж)


>FreeBSD rfork появился раньше, умеет то же, что и линуксовый clone(2) - и при этом "линуксоиды решили"?

http://www.linux.org.ru/jump-message.jsp?msgid=3424009&cid=3425124
Цитата: "с помощью этой вашей clone легко реализовать и fork, и vfork, а в 2.4 и треды на clone были сделаны. Вот что значит настоящая гибкость, не то что в допотопной бзде."

>И при этом "никаких аналогов clone в других Unix/POSIX-ядрах нет"?

Представь себе, нет.
Такие комбайны могут изобрести только линуксойды, перелезшие с Windows.

>Какой еще M:N, NPTL реализует 1:1. Какая еще System V, NPTL специфична для Linux.

Почитай для начала Википедию, а потом историю создания Solaris, что ли.

>NPTL использует clone(2), причем для NPTL туда был добавлен еще один флаг.

Ещё один флаг! Ещё один флаг! Я знал! Я знал! Что этим всё закончится!... Хм,... продолжится. Ж) Lindows-way...

>когда аргументы кончаются, нужно цепляться к словам Держите его четверо, да покрепче! Психиатров сюда.

Изен, ты обделался конкретно. И не надо опавдыватся, а то бредишь все жестче.

> http://www.linux.org.ru/jump-message.jsp?msgid=3424009&cid=3425124 Цитата: "с помощью этой вашей clone легко реализовать и fork, и vfork, а в 2.4 и треды на clone были сделаны. Вот что значит настоящая гибкость, не то что в допотопной бзде."

И что? Ни одной фактической ошибкм - в 2.4 нити были на clone. А вот ты продемонстрировал невежество, сказав, что в 2.6 NPTL не использует clone(2).

>>Какой еще M:N, NPTL реализует 1:1. Какая еще System V, NPTL специфична для Linux.

>Почитай для начала Википедию, а потом историю создания Solaris, что ли.

Я читал всё это, а вот ты откровенно бредишь.

>>NPTL использует clone(2), причем для NPTL туда был добавлен еще один флаг.

>Ещё один флаг! Ещё один флаг! Я знал! Я знал! Что этим всё закончится!

Посчитай количество флагов в rfork(2), и сравни.

Ладно, что-то стал твой бред надоедать. Было весело, зрители всё поняли - пора заканчивать.

>Изен, ты обделался конкретно. И не надо опавдыватся, а то бредишь все жестче.

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

>А вот ты продемонстрировал невежество, сказав, что в 2.6 NPTL не использует clone(2).

Бред. Я говорил, что clone(2) в Linux 2.6 стал ненужным комбайном, так как большая часть поддержки многопоточной функциональности перешла к NPTL.
"NPTL имеет некоторые сходства с LinuxThreads, такие как первичная абстракция ядра тоже процесс или новые потоки создаются вызовом clone()." — ещё одно оправдание присутствия clone(2)... ну ты понял.

За темой следи. Я ссылку давал, а ты всё со своим rfork(2) зафлудил всю тему.

>Какой еще M:N, NPTL реализует 1:1. Какая еще System V, NPTL специфична для Linux.

Не обращай внимания.
Эта была проверка тебя на знание архитектуры.

>Посчитай количество флагов в rfork(2), и сравни.
В rfork(2) флагов было 5 (в одной из первых FreeBSD), со временем стало 8 (FreeBSD 7.1).

В clone(2) флагов около 20 наберётся.

мну ламеры учат, дожили

>Клево, чем это отличается от fork exec? Ну да, вопрос глупый, тыж нихрена в линуксах не петришь.

тут бы рассказать кисам, что вообще делает форк, как работает механизм страничной трансляции адресов, что такое COW... но они ведь "в линуксах петрят". куда нам, ядерным разработчикам...

>Через параметр CLONE_VFORK системного вызова clone(2), дружочек.

Во-первых, я тебе не дружочек. Во-вторых, какая разница через что?

Цитирую тебя:

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

Итак, в Linux при использовании vfork родительский процесс тоже блокируется, тоже разделяет память с дочерним. Точно также vfork даёт некоторый прирост производительности по сравнению с fork.

Что тебя конкретно не устравает в линуксовом vfork?

>Бред. Я говорил, что clone(2) в Linux 2.6 стал ненужным комбайном, так как большая часть поддержки многопоточной функциональности перешла к NPTL.

Приз за упертость, NTPL использует clone.

>В clone(2) флагов около 20 наберётся.

Согласно ману - ровно 10, что намного ближе к 8 чем к 20.

>Что тебя конкретно не устравает в линуксовом vfork?

Синтаксис.

для ламеров, считаем байты

х86-32, c-calling convention, регистры под сохранение, если шедулинг идет через некую С-функцию: ESI, EDI, ESP, EBP - 16 байт. сегментные регистры CS,DS,SS,ES,FS,GS - обычно не используются, хотя для TLS переменных надо колбасить базу FS. т.е. еще и смещение TLS надо хранить (+2-4 байта) неплохо бы еще помнить, а откуда нас вообще позвали, чтоб туда вернуться. т.е. +4 байта EIP предполагаем DF=0, TF=0 т.е. помнить их не надо.

всё, меньше нельзя. никак. 22 байта, это тот самый минимум, который можно получить на x86.

для полного контекста еще EAX,ECX,EDX,EBX - еще 16 байт

контекст FPU - минимум 108 байт(man fsave/frstor), для SSE 512 байт(man fxsave/fxrstor)

в обчем, 22 байта в фальшивых однопоточных потоках, 38 байт в честных целочисленных потоках, и от 146 до 550 байт на вообще честных потоках

"петрящим в линуксе" рекомендую все это забыть как страшный сон.

>Синтаксис.

Ты точно здоров? Синтаксис vfork у FreeBSD и Linux одинаков:

pid_t vfork(void);

>Согласно ману - ровно 10, что намного ближе к 8 чем к 20.

Я насчитал 22:
http://www.kernel.org/doc/man-pages/online/pages/man2/clone.2.html

следите за руками

>A-234: Вот ты клоун, по ссылке сходи сначала.
cходил по ссылке, увидел это:

>pc_thread_context_t * const cc = malloc(sizeof(*cc));
>pc_thread_context_t * const pc = malloc(sizeof(*pc));

>Минимальный (два байта на поток) оверхэд и высокое быстродействие
открывают широкие перспективы для новой технологии.

два байта превращаются, превращаются... в sizeof(pc_thread_context_t) и укозатель на него.

ппц напёрсточники

Прототип функции:

int clone(int (*fn)(void *), void *child_stack,
int flags, void *arg, ...
/* pid_t *pid, struct user_desc *tls, pid_t *ctid */ );

>>Клево, чем это отличается от fork exec? Ну да, вопрос глупый, тыж нихрена в линуксах не петришь.

>тут бы рассказать кисам, что вообще делает форк, как работает механизм страничной трансляции адресов, что такое COW...

Просто расскажи, чем (в плане производительности) fork+COW+exec отличается от CreateProcess или bugagaexec.

> куда нам, ядерным разработчикам...

Анонимные аналитики, анонимные разработчики анонимных ОС, анонимные ядерные разработчики... ЛОР всё еще торт %)

>Прототип функции:

>int clone(int (*fn)(void *), void *child_stack,

>int flags, void *arg, ...

>/* pid_t *pid, struct user_desc *tls, pid_t *ctid */ );

Я не понял. Ты чего clone'ом размахиваешь, когда речь идёт о vfork? vfork в Linux есть? Есть. Работает в соответствии с POSIX? Работает. Работает быстрее, чем fork? Да, быстрее.

Т.е. со своей задачей справляется + переносим. Какие проблемы?

> Я насчитал 22:

> http://www.kernel.org/doc/man-pages/online/pages/man2/clone.2.html

Вот когда во FreeBSD появятся namespace'ы и контейнеры (если они появится), тогда и в ней появятся новые флаги rfork. Ну и то, что rfork не умеет указвать, какие _уже существующие_ в FreeBSD нужно клонировать - не является достоинством FreeBSD.

P.S. нет, chroot jail не является контейнером.

>Я не понял. Ты чего clone'ом размахиваешь, когда речь идёт о vfork? vfork в Linux есть? Есть. Работает в соответствии с POSIX? Работает. Работает быстрее, чем fork? Да, быстрее.

>Т.е. со своей задачей справляется + переносим. Какие проблемы?

Проблема 1.
vfork(2) в Linux работает через комбайнёрский вызов clone(2).

Проблема 2.
Сама суть clone(2) от этого страдает ещё больше: вместо следования Unix-way Linus выбрал Lindows-way — нафаршировывая каждую мажорную версию своего ядра новыми фичами, добавляет в clone(2) нужное количество флагов. Вместо реализации полновесных системных вызовов, пере/дописывается суперкомбайн clone(2) и делаются к нему вызовы со спецаргументами из тел новых функций.

>Проблема 1.

>vfork(2) в Linux работает через комбайнёрский вызов clone(2).

Я ему про Фому, он мне про Ерёму... %)

Уж что созданы эти т.н. "потоки" не идеях Erlang - этточно. Адам нечто иное курил - и вопрос в студию: каковы эти потоки в плане параллелизьма и прочей кошерности?

> каковы эти потоки в плане параллелизьма и прочей кошерности?

Никаковы :)

>и вопрос в студию: каковы эти потоки в плане параллелизьма и прочей кошерности?

На винде они оборачиваются в threads, в Unix они оборачиваются в vfork(2)/pthreads, в Linux они оборачиваются в clone(2) Ж) , в Solaris они оборачиваются в LWP+pthreads.

Сами по себе они чисто абстрактные и не работают. Ж)

> С разработкой библиотеки NPTL в Linux 2.6 (декабрь, 2003г) надобность в услугах комбайнёрского вызова clone(2) исчезла.

Я же просил троллить тоньше!

iZEN опять метанировал. Все кто ходили по ссылке видели, что эти "потоки" просто обертка над return/goto...

когда я увижу обоснование двух байтов на поток?

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

> когда я увижу обоснование двух байтов на поток?

Для начала пойми, что эти protothreads - не threads вообще.

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

Еще раз повторю - это не нити. У них нет раздельных значений регистров.

Значит, не показалось :) Re: Какая-то фигня

Тоись главное что я уяснил для себя: эти protothreads как ни назови, нужны лишь для того чтобы заполонить мозги еще одним (НЕНУЖНЫМ) псевдоAPI :) Выгод почти не видно: - Yet another API - Доп расход памяти + Портируемость (???) + ээээ? Неужто PROFIT ???

Я по ссылкам на LOR'е не хожу! Не нарушаю традиции! Так что со всей уверенностью могу сказать: ДА, это так.

"накладные расходы на общие данные" - пердеж в лужу. не продолжайте плз.

По сабжу.

В коде ядра sys_clone() ни чего не поменяли, значит ни чего радикального не изменилось. Поменяли обёртку в юзерспейсе над sys_clone(). Какую проблему решает сабж, какие плюсы даёт - это мне не понятно. По части производительности, может оно и даёт эффект. Только насколько повысится производительность системы в целом от внедрения таких вызовов? Часто ли создаются и убиваются нити?

>>Вот когда во FreeBSD появятся namespace'ы и контейнеры (если они появится), тогда и в ней появятся новые флаги rfork. Ну и то, что rfork не умеет указвать, какие _уже существующие_ в FreeBSD нужно клонировать - не является достоинством FreeBSD.

не появятся. на почтовых/веб серверах они не нужны =] а на что то более серьезное фря не тянет.

> В коде ядра sys_clone() ни чего не поменяли, значит ни чего радикального не изменилось. Поменяли обёртку в юзерспейсе над sys_clone(). Какую проблему решает сабж, какие плюсы даёт - это мне не понятно.

А с чего вдруг стало бы понятно, если даже не удосужился уяснить, что сабж не имеет ровным счётом никакого отношения к pthreads, clone и аппаратной многозадачности... Кстати, в этом и плюсы.

>когда я увижу обоснование двух байтов на поток?

Да яж привел тебе абзац где про два байта написано, учи английский. Думаешь раз осилил книжку "Архитектура и программирование процессора Intel 386" значит стал разработчиком ядра ОС? Не смеши мои тапки, кроме интеловой существует еще куча архитектур на которых работает ядро линукс. Открою тебе страшную тайну - не все из них поддерживают страничную адресацию. Но я тебе дам пищу к размышлению мой юный друк, раз ты так присел на интела следующим шагом твоего саморазвития будет архитектура AMD64, она тебя удивит.

2iZEN>Я насчитал 22:

> http://www.kernel.org/doc/man-pages/online/pages/man2/clone.2.html

Да, я тоже насчитал 22. Но по сути что это меняет? По аналогии, будем каждый раз называть printf костылем когда в нем станут появляться новые модификаторы? Этому "костылю" лет побольше чем некоторым лоровским анонимусам. Такое впечатление что эволюционный путь развития ядра линукс вас раздражает. На мой взгляд это наоборот разумно, понадобилась разработчикам новая функциональность, вместо того чтобы жевать сопли и откладывать релиз очередного ядра на пару лет, пока разработчиков не осенит идея новой концепции, просто берут и добавляют новые флаги.

>>>Этому "костылю" лет побольше чем некоторым лоровским анонимусам...

Не некоторым, а подавлющему большинству 8)))

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

во вторых, поток может встать где угодно, стало быть надо помнить хотя бы точку останова (EIP/RIP), в стеке могут лежать локальные переменные, стало быть его тоже надо помнить(ESP/RSP). это уже 8 байт минимум. это - такое имманентное свойство потока, и заклинаниями его не отменишь.

НАКОНЕЦ, рекомендую осилить англицкий езыг, и увидеть: >Each thread needs a context structure: > typedef struct { > pt_thread_t pt_thread; > pt_func_t pt_func; > int i; > int * mailbox; > } pc_thread_context_t; подумать башкой, сколько весит sizeof(int) и sizeof(int*) хотя бы. у мя нету там 2х байт. 2байта - это голимое наперсточничество.

> Просто расскажи, чем (в плане производительности) fork+COW+exec отличается от CreateProcess

Тем что fork+COW+exec быстрее? Кажись в NT CreateProcess медленный )

вся проблема forkа описана в мане на vfork

лишние таблицы карт памяти, массовый каст COWа на память родительского процесса, лишние операции с fd и т.д. и т.п. а юзают fork в основном для exec. так может быть, обзавестись уже отдельным forkо-execом?

>А с чего вдруг стало бы понятно, если даже не удосужился уяснить, что сабж не имеет ровным счётом никакого отношения к pthreads, clone и аппаратной многозадачности... Кстати, в этом и плюсы.

Дык пожалуйста, объясните, какую проблему снимает сабж? В чём приемущества?

> вся проблема forkа описана в мане на vfork

Там описана ровно одна проблема: "in the bad old days a fork() would require making a complete copy of the caller's data space, often needlessly, since usually immediately afterwards an exec() is done". Эта проблема уже решена.

> Такие комбайны могут изобрести только линуксойды, перелезшие с Windows.

а бсдуны никуда не перелезают традиционно) вот и на страничке у тебя какие-то поделки на дельфи под винду)

обана, что я вижу? "проблема уже решена"

ну и интересно, а каким же образом решена проблема COWа если он всё равно должен происходить со всеми записываемыми страницами пространства пользователя. даже если отбросить незаписываемые страницы, всё равно надо перелопачивать постранично все записываемые записи про них могут находиться в TLB и по возврате будут опять записываемы. так что invlpg на каждую страницу неизбежен, а на корадубах за невыполнение сего ритуала можно получить по роже в форме deadlockа проца

мне правда интересно, что за секретный метод обхода этого имманентного свойства форка?

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

> ну и интересно, а каким же образом решена проблема COWа

О проблемах COW никто (кроме тебя) не говорит. "would require making a complete copy of the caller's data space" - ты же понимаешь эту фразу? копирование _данных_. А сейчас копируются таблицы страниц.

> так что invlpg на каждую страницу неизбежен

Мне лень лезть в руководство по процессору, но даже если и так - какой процент чистых накладных расходов (по сравнению с CreateProcess) они составляют? Даже полный TLB flush - это всё равно копейки для такой операции, как создание процесса.

>О проблемах COW никто (кроме тебя) не говорит. "would require making a complete copy of the caller's data space" - ты же понимаешь эту фразу? копирование _данных_. А сейчас копируются таблицы страниц.

аха. и когда возникает exec и странички начинают меняться - возникает COW. в худнем своем варианте - когда выделяется память по одной страничке и кучка page fault. Не зря же придумали всякие prefault варианты... не от хорошей жизни уходят от COW.

> и когда возникает exec и странички начинают меняться - возникает COW

И причем здесь это вообще? Речь шла об эффективности fork+COW+exec. Для того, чтобы добежать от вызова fork до вызова exec, не нужно много страниц (я так думаю - 1 страница стека, максимум). Так в каком месте COW сильно влияет на производительность _данного случая_?

> Не зря же придумали всякие prefault варианты...

Их придумали для загрузки страниц с диска.

> не от хорошей жизни уходят от COW

Кто и куда уходит? Линк.

Феерический долбаеб ,-)

>ну и интересно, а каким же образом решена проблема COWа если он всё равно должен происходить со всеми записываемыми страницами пространства пользователя.

Если ты тот самый анонимус - разработчег ядра, то я обескуражен. Как происходит COW? Не волнуйся, не все там сложно я тебе сечас объясню. Для процесса потомка таблицы страниц создаются с запретом на запись в эти страницы. Дальше, когда потомок пытается писать в защищенную от записи страницу происходит что? Правильно, прерывание. Анализируя причину прерывания мы имеем ЛОГИЧЕСКИЙ (если тебе это о чем нибудь говорит) адрес. По логическому адресу "перелопачивать" ничего не надо, ты сразу имеешь индекс в каталоге таблиц, индекс в таблице и смещение (не заставляй меня писать подробности как это сделать, не позорься). Значит мы точно занем какую страницу необходимо дублировать. Понятно, что дублировать все сразу не имеет смысла, более того, оверхед зависит только от величины кешей процессора, чем они больше тем больше максимально возможный оверхед, но такой сценарий крайне маловероятен и кроме как на синтетических тестах не появляется.