LINUX.ORG.RU
Ответ на: комментарий от iliyap

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

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

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

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

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

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

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

Всё верно.

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от pathfinder

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от Tanger

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

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

bigbit ★★★★★
()

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

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

ixrws ★★★
()
Ответ на: комментарий от iliyap

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

ixrws ★★★
()
Ответ на: комментарий от ixrws

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от LamerOk

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

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

ixrws ★★★
()
Последнее исправление: ixrws (всего исправлений: 1)
Ответ на: комментарий от ixrws

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

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

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

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

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от LamerOk

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

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

X512 ★★★★★
()
Ответ на: комментарий от anonymous

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

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

X512 ★★★★★
()
Ответ на: комментарий от X512

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

X512 ★★★★★
()
Ответ на: комментарий от X512

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

anonymous
()
Ответ на: комментарий от X512

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

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от LamerOk

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

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

X512 ★★★★★
()
Ответ на: комментарий от X512

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от ixrws

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

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

iliyap ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

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

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

wiki

korvin_ ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

ixrws ★★★
()
Ответ на: комментарий от korvin_

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

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от ixrws

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

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

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

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от LamerOk

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

Точно.

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

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

anonymous
()
Ответ на: комментарий от LamerOk

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

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

ixrws ★★★
()
Последнее исправление: ixrws (всего исправлений: 1)
Ответ на: комментарий от iliyap

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

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

ixrws ★★★
()
Ответ на: комментарий от ixrws

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

anonymous
()
Ответ на: комментарий от interrupted

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

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

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

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

Oleg_Iu
()
Ответ на: комментарий от Oleg_Iu

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

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

X512 ★★★★★
()
Ответ на: комментарий от X512

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от ixrws

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

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

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от LamerOk

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

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от korvin_

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

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от LamerOk

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

ixrws ★★★
()
Ответ на: комментарий от X512

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

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

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

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

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

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

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

LamerOk ★★★★★
() автор топика
Ответ на: комментарий от LamerOk

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

ixrws ★★★
()
Последнее исправление: ixrws (всего исправлений: 1)
Ответ на: комментарий от LamerOk

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

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

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

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

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

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

X512 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.