fork() is evil;

Ещё один...

Негативные последствия получаются, когда делаешь форк из потока многопоточного процесса.

Оу щиит, а почему в мане на эту функцию в самом начале нет надписи вида: «ОПАСНО!!! Пользоваться с осторожностью»?

Оу щиит, а почему в мане на эту функцию в самом начале нет надписи вида: «ОПАСНО!!! Пользоваться с осторожностью»?

Потому что маны читать надо полностью, а не только в самом начале.

Потому что маны читать надо полностью, а не только в самом начале.

Ох, сказочный наш анонимус, всё то он знает.

Анонимус не врёт. В мане особо написано про форк многопоточного процесса, про использование исключительно async signal safe вызовов после fork вплоть до вызова execve. Ты же просил по рабоче-крестьянски объяснить, а не ман зачитывать.

Я с тобой ни в чем не спорю. Я со всеми твоими утверждениями согласен.

• Анонимус не врёт. (Но умничает там, где не просят)
• В мане особо написано про форк многопоточного процесса...
• Я просил по рабоче-крестьянски объяснить...

Всё верно.

Но умничает там, где не просят

Это тред для тех, кто хочет поумничать. Для дураков есть весь остальной лор.

Ох, LamerOk, зачем ты присоединился с этому спору? Ну ясно же, что продолжать эту дискуссию бессмысленно.

Чтобы бампнуть годный тред, очевидно же.

:) Ок, засчитывается.

Тогда что ты думаешь о posix_spawn(), как о замене fork()?

Я думаю, что самый лучший posix_spawn() это CreateProcess().

А про fork() всё развёрнуто в ссылке из ОП.

Зачем так делать?

Там анализируется код возврата. У шелла нулевой код возврата - это успех, у bool же все наоборот (0==false). Поэтому и нужно отрицание.

Что-то сосёт в одном случае, что-то в другом. Не понимаю я людей, которые разные API критикуют за дизайн. Ну так всегда будет. Что-то удобно в одном случае, что-то в другом. fork очень удобен и прост для написание каких-нибудь обработчиков логов на perl во столько процессов, сколько нужно. В каких-то случаях он неудобен и слишком высокоуровневый. Проблем с тем, чтобы использовать другое API под Linux нет, на все вкусы оно есть. То что одни и те же сущности называются и вызываются по разному в разных ОС это обычное дело. Даже обычные предметы в рамках одного языка в разных регионах могут называться по разному. Кому-то удобно так, кому-то по другому.

Ну а то все API имеют свои подводные камни знает любой, кто писал нативный код хотя бы под две разные операционки.

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

Едва ли fork разрабатывался как панацея

Алё, гараж. Форк был единственным вызовом/механизмом в юниксе для порождения процессов.

А ничего, что unix тех времён не была операционкой панацеей хотя бы потому, что тех задач, что стоят сегодня перед приложениями тогда попросту не было и таких сложных приложений тоже? Я к тому, что fork создавался в тех условиях, когда делать приложения, порождающие процессы, затем потоки, затем процессы и тд и любой вложенности - было просто негде и незачем. Незачем потому что не было задач. А негде, потому что не позволяло железо. Вот когда стало позволять - любая unix подобная система обзавелась соответствующими возможностями. Но это не повод не использовать fork там, где он удобен и уместен.

Напомню также, что в те времена были ещё популярны операционки без такого явного отделения процессов приложений, те самые, на основе идей которых потом возник dos. И они также имели право на жизнь и даже сейчас такой подход имеет на жизнь много где. Но надо вот обязательно поныть как плох fork для каких-нибудь нагруженных сложных приложений. Можно также поныть и про то, что уникода во многих старых API тоже нет, и чего?

Ты не можешь ничего из этого «напомнить», потому что ты ничего про это не знаешь, так как являешься безграмотным школьником.

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

Вообще-то, форк именно для этого и создавался - запускать кучи программ-фильтров на текстовых данных. Это было основное назначение unix как операционной системы.

операционки без такого явного отделения процессов приложений, те самые, на основе идей которых потом возник dos

DOS не имел поддержки многозадачности, потому что работал на однопроцессорном железе без необходимой для этого аппаратной поддержки, а не потому, что нафантазировал твой школомозг.

Короче, на пересдачу. Летнюю сессию ты завалил, осенью приходи.

DOS не имел поддержки многозадачности, потому что работал на однопроцессорном железе без необходимой для этого аппаратной поддержки

Для многозадачности никакая специальная аппаратная поддержка не нужна. Любая Тьюринг-полная машина способна на многозадачность. Это DOS не способен потому что оно и не ОС вовсе, а драйвер файловой системы.

для настоящей нужны настоящие отдельные процессоры/потоки. иначе будет эмуляция

для настоящей нужны настоящие отдельные процессоры/потоки. иначе будет эмуляция

Это всё чисто программно реализуется. Смотрите исходники xv6. Когда-то делали аппаратные задачи, но этот подход устарел и в новых процессорах так не делают.

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

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

Потоков обычно больше чем ядер так что по любому всё одновременно исполнятся не будет и будут использоваться программные переключения.

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

Для многозадачности никакая специальная аппаратная поддержка не нужна.

Не надо теребить границы общепринятых терминов. Мы не обсуждаем здесь green threads или способности DOS Navigator'а показывать тетрис во время копирования файла. Мы говорим только о «настоящей», т.е. реализованной аппаратно «многозадачности» с виртуальным адресным пространством для каждой задачи.

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

Мы говорим только о «настоящей», т.е. реализованной аппаратно «многозадачности» с виртуальным адресным пространством для каждой задачи.

Это называется защита памяти, а не многозадачность.

Это называется защита памяти

Защита чьей памяти и от кого?

А какими именно соответствующими возможностями обзавелся линукс? Есть другой способ создавать процессы, кроме клонирования (и связанной с клонированием необходимостью в оверкоммите памяти)?

Про проектирование тоже непонятно, что конкретно ты предлагаешь. Не форкать многопоточные процессы? Но как тогда из многопоточного процесса запустить чайлд с какой-нибудь утилитой – kmod, iptables-save, да что угодно. Не запускать?

Не надо теребить границы общепринятых терминов. Мы не обсуждаем здесь green threads или способности DOS Navigator'а показывать тетрис во время копирования файла. Мы говорим только о «настоящей», т.е. реализованной аппаратно «многозадачности» с виртуальным адресным пространством для каждой задачи.

DOS не имел поддержки многозадачности, потому что работал на однопроцессорном железе без необходимой для этого аппаратной поддержки, а не потому, что нафантазировал твой школомозг.

Сколько процессоров было в PDP-11?

Виртуальная память в архитектуре x86 была реализована с появлением защищенного режима процессора 80286, однако она использовала сегментацию памяти, и метод подкачки сегментов плохо масштабировался для больших размеров сегментов. В процессоре 80386 была введена поддержка подкачки страниц, не приводящая к возникновению двойной ошибки, если во время обработки другого исключения возникло исключение ошибки страницы. Поверх системы подкачки страниц работал существующий механизм сегментации памяти.

— wiki

Плохо когда самомнение на небесах:) Никакой кучей данных во времена unix никто не оперировал, тому было много причин, в том числе малая ёмкость носителей, так что не надо басен из своего воспалённого воображения. Unix был упрощённой версией multics в том числе из-за очень малых ресурсов тогдашних машин. DOS просто не имел встроенных средств для управления процессами, но это не значит что там нельзя было иметь процессы. А Unix и предшественники DOS вращались на не сильно отличающемся на тот момент железе. Не надо брать в расчёт появившиеся в 80е железяки для бизнеса, на которых вращались коммерческие Unix, это уже была совсем другая история и там уже как раз API развивалось.

Очень надеюсь, что студенты сдают сессию не таким вот мнимым профи, а то отрасли совсем трындец. Мне же несколько поздно что-то сдавать:)

DOS не имел поддержки многозадачности, потому что работал на однопроцессорном железе без необходимой для этого аппаратной поддержки

Сколько процессоров было в PDP-11?

Именно, дурачёк. В PDP-11 необходимая поддержка была.

Никакой кучей данных во времена unix никто не оперировал, тому было много причин, в том числе мои школофантазии

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

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

Мне же несколько поздно что-то сдавать:)

Жаль, тебе бы не помешало.

В PDP-11 необходимая поддержка была.

Конкретней говори, сколько процессоров там было?

Не надо теребить границы общепринятых терминов.

Точно.

Мы говорим только о «настоящей», т.е. реализованной аппаратно с виртуальным адресным пространством

Какой в сраку «настоящей т.е. реализованной аппаратно» , открой дядьку Таненбаума и не выпендревайся. Заодно mpu на википедии и Efficient software-based fault isolation от Wahbe и иже с ним.

Ну давай тогда по проще, а то твоё эго не позволят тебе сложнее. Насколько быстрее происходит обработка скажем сотни тысяч текстовых файлов в 100 процессов, чем скажем в 2, с учётом того, что на машине того времени один процессор, памяти думаю сам загуглишь на сколько реально параллельных процессов хватит и скорость ио ну не то чтобы перфокартная, но тоже так себе? Иными словами где будет затык и почему миллионы форков твоего воображения никак не помогут?

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

Речь про коммент про fork. В случае Linux это clone и exec, комбинации которых достаточно для жизни в самых сложных ситуациях. Ну и конечно clone в разных его вариациях даёт больше возможностей, чем fork из unix времён 70-начала 80х. Но тогда и cpu были несколько другие.

Что до проектирования, то предлагаю сначала изучать API и подводные камни, а потом ныть. Это собственно и называется проектирование. А когда люди начинают с наскока писать, а потом в процессе оказывается что что-то ломается в самом неудобном месте - как это называется?

Это DOS не способен потому что оно и не ОС вовсе, а драйвер файловой системы.

Почему-то приходит в голову DESQview.

desqview не входил в состав дос

Это называется «абстаркция».

desqview не входил в состав дос

Ну в состав DOS много чего не входило. Например, драйвер клавиатуры keyrus Димы Гуртяка не входил в DOS, но, как ни крути, все же был частью DOS.

Сама DESQview не ялвялась отдельной OS, а была всего-лишь контроллером многозадачности DOS, для запуска dos-программ, и никаких других.

PS А docker не вохдит в состав линукса, и чё? :) :) :)

Почему-то приходит в голову DESQview.

Это по сути отдельная ОС, переопределяющая больную часть кода DOS. Сам DOS в принципе не способен на многозадачность. Была ещё якобы многозадачная DOS, но на самом деле это было ядро Win16 без GUI.

якобы многозадачная DOS, но на самом деле это было ядро Win16

Ох, лол. Win 16 точно такая же «однозадачная» как DOS.

Какой в сраку «настоящей т.е. реализованной аппаратно» , открой дядьку Таненбаума и не выпендревайся. Заодно mpu на википедии
A memory protection unit (MPU), is a computer hardware unit

Какая буква в слове «hardware» тебе не понятна?

Насколько быстрее

Ты дурачёк или да? Впрочем, можешь не отвечать.

конвеерный подход полностью последовательный

Выходи к доске и расскажи, сколько процессов будет создано в shell при использовании конвейера?

Win 16 точно такая же «однозадачная» как DOS.

В Win 16 есть короутины и кооперативная многозадачность. Если вы вызовите Yield(), GetMessage() и др., то ядро может переключить на другую задачу с другим стеком и состоянием регистров процессора. DOS так не умеет, там просто нет механизмов и API для переключения.

Конкретней говори

Говорю конкретно - ты не способен прочитать и осмыслить ветку из трёх связанных постов.

Говорят, это «дислексия». Я не знаю, лечится ли это.

Какой-то комплекс учителя и похоже просто плохое знание предмета. Не разработчик? Ну так бы сразу и писал, что теоретик-кукаретик.

В Win 16 есть короутины и кооперативная многозадачность

Не надо дублировать маркетинговый буллшит от МС. Это никакая не «многозадачность», а способность расширять возможность текущего кода загрузкой дополнительного исполняемого кода в общее адресное пространство.

В эпоху настоящей многозадачности это стало называться «загрузкой плагинов».

Yield(), GetMessage() и др., то ядро может переключить на другую задачу

И чем это отличается от DllAttach() на LoadLibrary()? Правильно, ничем. У нас теперь любой вызов кода из внешнего бинарника - «многозадачность»?

DOS так не умеет, там просто нет механизмов и API для переключения.

Ты просто слишком маленький, чтобы застать термин «резидентная программа».

Садись, два.

А меня за это выгонять из твоей воображаемой школы? Просто интересно, вот допустим поставил мне кол. А какие будут последствия?:)

а способность расширять возможность текущего кода загрузкой дополнительного исполняемого кода в общее адресное пространство.

Хватит уже путать многозадачность и защиту памяти. В Win16 можно запустить аудиопроигрыватель, видео, игру и т.д и всё это будет одновременно работать.

И чем это отличается от DllAttach() на LoadLibrary()?

Многозадачность и динамическая загрузка модулей – это совершенно разные независимые механизмы. Учите матчасть.

Ты просто слишком маленький, чтобы застать термин «резидентная программа».

Это кривой костыль, не способный нормально работать.