Re: xserver-xorg и hal
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.
Reply to: