Билл Гейтс, нобелевка и битвы на кухне

[f_evgeny]

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

OMG. Как вы себе представляете эти нулевые затраты ресурсов при клонировании процесса? Процессором это не поддержтивается, нет там такой команды как копирование процесса, поэтому на самом деле происходит большое кол-во операций при копировании процесса.

В таблицах ядра создается только копия записей процесса родителя, больше ничего не делается. Это требует очень небольших затрат. Память физически не выделяется, процесс-наследник работает с той же памятью (если он только читает). И только если процесс потомок хочет что-тозаписать в память, ему для записи выделяется страница памяти, куда он и пишет. Называется copy-on-write.

[f_evgeny]

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

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

Думаете, что в POSIX просто так для красоты ввели pthread ?

Просто в ЮНИКСах эффективность потоком и процессов (по крайней мере при создании) - приблизительно одинакова. К сожалению при оценке этого совершенно не принимают во внимание, что общение между потоками быстрее, чем между процессами.

Архитектуру нужно выбирать, исходя из специфики задачи. Иногда лучше треды, иногда форки, иногда форки плюс треды.
Кстати, многие программы стали использовать треды для переносимости на Win32.
А насчет ПРАВИЛЬНЫХ программ это Вы хорошо заметили, только вот к сожалению мир несовершенен и в 99.3% программ присутствуют различной тяжести баги. Программы написанные на процессах избавляют еще и от утечек, кстати.

[Tropik]

Называется copy-on-write.

Спасибо за обьяснение

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

[Tropik]

Программы написанные на процессах избавляют еще и от утечек, кстати.

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

try {
... код ...
}
catch(NullPointerException ex) {
}

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

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

[f_evgeny]

Называется copy-on-write.

Спасибо за обьяснение

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

Смотря какими данными обмениваться и как. Например сетевые запросы обрабатывать проще и работать будет надежнее, если написать на процессах.

[Tropik]

Смотря какими данными обмениваться и как. Например сетевые запросы обрабатывать проще и работать будет надежнее, если написать на процессах.

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

Disclaimer: Я писал сетевые модули и для Windows и для *nix. Даже в Апачи есть кой-какой код, а написании которого я принимал участие.

[f_evgeny]

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

Вы просто не совсем наверное поняли: что имеется в виду. Например нужно сделать сокет сервер. Делаем форк на соединение, после обработки соединения из процесса выходим. И система сама заботится о памяти.

[f_evgeny]

Смотря какими данными обмениваться и как. Например сетевые запросы обрабатывать проще и работать будет надежнее, если написать на процессах.

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

Disclaimer: Я писал сетевые модули и для Windows и для *nix. Даже в Апачи есть кой-какой код, а написании которого я принимал участие.

Да ничего особенного. На особенность не претендуем. Просто легко написать неубиваемый сервер. Apache 1.3

[Tropik]

Да ничего особенного. На особенность не претендуем. Просто легко написать неубиваемый сервер. Apache 1.3

Здрасте Дайте в гугле поиск apache 1.3 crash

[f_evgeny]

Да ничего особенного. На особенность не претендуем. Просто легко написать неубиваемый сервер. Apache 1.3

Здрасте Дайте в гугле поиск apache 1.3 crash

Ну дал, в основном модули падают. И что? Похоже, что Вы притворяетесь, что не понимаете о чем речь.

[Tropik]

Да ничего особенного. На особенность не претендуем. Просто легко написать неубиваемый сервер. Apache 1.3

Здрасте Дайте в гугле поиск apache 1.3 crash

Ну дал, в основном модули падают. И что? Похоже, что Вы притворяетесь, что не понимаете о чем речь.

А как вы себе представляете Апачи без модулей? Это все-равно что Windows без программ и сервисов написанных другими разработчиками. Тоже падать не будет.

[f_evgeny]

А как вы себе представляете Апачи без модулей? Это все-равно что Windows без программ и сервисов написанных другими разработчиками. Тоже падать не будет.

Так падает дочерний процесс. Сервер остается работать.

[Tropik]

А как вы себе представляете Апачи без модулей? Это все-равно что Windows без программ и сервисов написанных другими разработчиками. Тоже падать не будет.

Так падает дочерний процесс. Сервер остается работать.

А толку от сервера, если модуль навернулся? Представьте, что у вас сайт написан на PHP, при этом сервер крутится под Апачи, а PHP модуль навернулся. Много толку от вашего сайта теперь будет?

[f_evgeny]

А толку от сервера, если модуль навернулся? Представьте, что у вас сайт написан на PHP, при этом сервер крутится под Апачи, а PHP модуль навернулся. Много толку от вашего сайта теперь будет?

Блин, Вы это серьезно пишете? Не могу поверить.
Навернулся модуль при обслуживании одной страницы в процессе-потомке. Этот процесс завершается. Упал один процесс-ребенок. Все остальное работает. Сам процесс-родитель и остальные детки. В том числе и с таким же модулем на других страницах.
Альтернатива на тредах. Падает все.
Или я неправ и что-то не так понимаю?

[Tropik]

Альтернатива на тредах. Падает все.
Или я неправ и что-то не так понимаю?

Да не падает всё Вы в каком веке живете?
Вот вам пример, что даже Апачи начинает использовать гибрид threads и processes. Apache MPM (это то, где есть и часть моей работы). Все хорошо в меру. И когда кто-то (как вы) начинает утверждать, что потоки - это плохо, а процессы - хорошо, то сразу видно человека, который не занимался программированием действительно scalable software.

[f_evgeny]

Альтернатива на тредах. Падает все.
Или я неправ и что-то не так понимаю?

Да не падает всё Вы в каком веке живете?
Вот вам пример, что даже Апачи начинает использовать гибрид threads и processes. Apache MPM (это то, где есть и часть моей работы). Все хорошо в меру. И когда кто-то (как вы) начинает утверждать, что потоки - это плохо, а процессы - хорошо, то сразу видно человека, который не занимался программированием действительно scalable software.

Клевета! Вы, собственно читали, то что я писал? Я именно писал, что нужно исходя из требований к приложению выбирать архитектуру. И лучше иметь форк, чем его не иметь. Да Вы и сами признавали, что надежность на форках выше.
А вот если Вы способны неангажированно обсуждать тему (пока на это не похоже) и имеете отношение к Apache, то было бы интересно, если бы Вы сообщили Ваше мнение, из-за чего Апач стал использовать треды. Для обеспечения переносимости на Win32, или по другим соображениям?

[f_evgeny]

Да не падает всё Вы в каком веке живете?

Может я действительно отстал от жизни, но мне показалось, что Вы утверждаете, что приложение написанное на тредах не может полностью упасть из-за краха в одном треде? Проясните пожалуйста Вашу точку.

[Tropik]

Клевета! Вы, собственно читали, то что я писал? Я именно писал, что нужно исходя из требований к приложению выбирать архитектуру. И лучше иметь форк, чем его не иметь. Да Вы и сами признавали, что надежность на форках выше.

Создание нового процесса имеет смысл только в том случае, если "хозяин" признает, что имеет баги и не может их найти (т.е. фактически программисты признают, что не могут пофиксить проблемы), или как в случае с браузерами, если браузеру приходится иметь дело с 3rd party plugins. Т.е. когда в том же Internet Explorer приходится грузить всякие Флеш и т.п. плагины, за которые браузер отвечать не может, т.к. это делается другой группой программистов. Т.е. все упирается в то, что приходится осознавать, что в твоем контейнере всякие плохие прогаммисты будут грузить плохо оттестированный софт.

А вот если Вы способны неангажированно обсуждать тему (пока на это не похоже) и имеете отношение к Apache, то было бы интересно, если бы Вы сообщили Ваше мнение, из-за чего Апач стал использовать треды. Для обеспечения переносимости на Win32, или по другим соображениям?

По другим соображениям. А именно, что используя MPM технологию - Апачи работает быстрее и потребляет меньше ресурсов.

[Tropik]

Да не падает всё Вы в каком веке живете?

Может я действительно отстал от жизни, но мне показалось, что Вы утверждаете, что приложение написанное на тредах не может полностью упасть из-за краха в одном треде? Проясните пожалуйста Вашу точку.

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

[Tropik]

К сожалению приходится констатировать, что разработчики выбирают более простой путь. Это относится как к Майкрософту, так и к Гуглу и к другим производителям. А именно - стало модно запихивать различные задачи в отдельные процессы. Ес-но - ведь проще убить процесс, чем разбираться, почему собственно это привело к ошибке.

[f_evgeny]

...плохо оттестированный софт...

Ага! Вот в чем коренная причина наших разногласий! Вы значит считаете, что есть некий "хорошо оттестированный софт"?
По этому вопросу мое мнение такое. Софт, а особенно написанный в объектном стиле, более того многозадачный, имеет столько степеней свободы, что даже надеятся на то, что можно все степени свободы протестировать, по меньшей мере наивно.

[f_evgeny]

К сожалению приходится констатировать, что разработчики выбирают более простой путь. Это относится как к Майкрософту, так и к Гуглу и к другим производителям. А именно - стало модно запихивать различные задачи в отдельные процессы. Ес-но - ведь проще убить процесс, чем разбираться, почему собственно это привело к ошибке.

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

[Tropik]

...плохо оттестированный софт...

Ага! Вот в чем коренная причина наших разногласий! Вы значит считаете, что есть некий "хорошо оттестированный софт"?
По этому вопросу мое мнение такое. Софт, а особенно написанный в объектном стиле, более того многозадачный, имеет столько степеней свободы, что даже надеятся на то, что можно все степени свободы протестировать, по меньшей мере наивно.

Ну в принципе я с вами согласен. Но нужно стремиться ошибки исправлять. Особенно в коммерческом платном софте (в free open-source софте тоже, если они конкурируют с коммерческим). Поэтому использовать процессы просто как средство скрыть ошибки - считаю недопустимым.

[Tropik]

К сожалению приходится констатировать, что разработчики выбирают более простой путь. Это относится как к Майкрософту, так и к Гуглу и к другим производителям. А именно - стало модно запихивать различные задачи в отдельные процессы. Ес-но - ведь проще убить процесс, чем разбираться, почему собственно это привело к ошибке.

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

Да то-же самое можно и с потоками сделать. Особенно в высокоуровневых языках (типа Java). Спокойно можно все исключения отлавливать на уровне потока. И ес-но в C/С++ тоже можно

[f_evgeny]

Да то-же самое можно и с потоками сделать. Особенно в высокоуровневых языках (типа Java). Спокойно можно все исключения отлавливать на уровне потока. И ес-но в C/С++ тоже можно

Можно-то можно. Это теоретически. Однако же, если спуститься на грешную землю, остается несколько контрольных точек:
1) необходимый уровень надежности
2) минимальные трудозатраты
3) приемлемую производительность
Вот исходя из этих пунктов и нужно исходить, ИМХО, конечно. процессы легче обеспечивают 1) и 2), треды - 3) и 2). 2) в обоих случаях потому, что на тредах проще IPC, но нужно больше тестирования и тщательнее относиться к багам для обеспечения той же надежности, а это трудозатраты и деньги.