On 2009.05.04 at 18:59:24 +0900, Anton Anikin wrote: > > Мое "категоричное" утверждение было о том, что БЫВАЮТ задачи для которых > > нити действительно полезны и БЫВАЮТ программисты, которые способны с > > ними в этой ситуации справиться. Но в 90% задач существуют более > > надежные решения. И более простые, которые можно уложить в голове у > > нормального программиста, а не супергения. > > > > Ситуации бываю разные. И методы их решения тоже. Предложите варианты > (переносимые) для эффективной масштабируемости на SMP-системах. Я уже писал > об этом выше.
Варианты чего? Сервера, обслуживающего многочисленных клиентов? Вот он прекрасно масштабируется fork-ом. И переносимость его на платформы, не умеющие fork - неинтересна. Для этих платформ аналогичный продукт надо писать с нуля с принципиально иными архитектурными решениями. > Отказ от ООП как такового вовсе не гарантирует вам хорошего качества продукта > на выходе. Зачастую такого понапишут, что черт ногу сломит. Для ООП это тоже > актуально, поэтому, как мне кажется, всё зависит от квалификации > разработчика. Если она недостаточна, то ни ООП, ни процедурный стиль, ни > функциональный не дадут вам удовлетворительный результат. Вопрос в том, какая именно квалификация достаточна. Для архитектуры без ООП и без нитей достаточна намного меньшая квалификация, чем для грамотного использования того или другого. > "следует избегать елико возможно" - это вы сами придумали ? Или есть > рекомендации в серьезных источниках ? Какие источники вы считаете серьезными? Маркетинговый бред "банды четырех"? > > А вот задачи с которыми пользователь имеет дело каждый день - браузер, > > X-сервер, текстовый редактор etc просто НЕ ИМЕЮТ права падать. Даже в > > случае заведомо неправильных действий пользователя. > > Т.е. из этой фразы можно сделать вывод, что нити - потенциально ведут к > падениям ПО, написанного с их использованием ? Странно как-то это звучит. Нити подразумевают что несколько потоков выполнения одновременно обращаются к общей памяти. Причем, как правило, в этой памяти еще и указатели бывают. Отсюда один шаг до сегфолта в случае ошибки синхронизации. > Т.е. если мы все напишем через FSM или fork, то программа сразу будет > являться образцом стабильности и надежности? Ну-ну. Ну не то, чтобы сразу. Но добиться надежной работы в этих условиях гораздо проще. Потому что гораздо легче предсказать содержимое любого участка памяти. Кстати не "FSM или fork", а, как правило, "FSM и fork". Только в очень редких случаях при реализации многопроцессной модели удается обойтись без процесса-менеджера, который распределяет доступ к общим ресурсам. Этот процесс должен обрабатывать поток запросов от нескольких других процессов, поэтому должен иметь FSM. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org