[Moscow.pm] чем плох девелоперский веб-сервер catalyst

[Naim Shafiev]

Почему?объясните несведущему

12 декабря 2008 г. 12:14 пользователь Анатолий Шарифулин <
sharifulin на gmail.com> написал:

> треды -- это жопа, замена тредов в Perl -- Coro.
>
> 11 декабря 2008 г. 23:19 пользователь Naim Shafiev <shafiev на gmail.com>написал:
>
> Хватит гнать на gccшников :).Софт должен поддерживать  тредовость и
>> параллелизм.
>>
>> 11 декабря 2008 г. 23:15 пользователь Михаил Монашёв <
>> postmaster на softsearch.ru> написал:
>>
>> Здравствуйте, Сергей.
>>>
>>> >> Вообще,  в  теории,  наверное  можно  написать такой перл (седьмой?
>>> >> :-)),  который  сам  бы  внутри  себя  мультиплексировал запущенные
>>> >> процесс  и переписывать под мультиплексирование приложения не нужно
>>> >> было  бы.  А  сейчас  конечно  под  Каталист  HTTP-движок         с
>>> >> мультиплексированием никак не сделать.
>>>
>>> СМ> Миш,   по  моему  дело  все  в  том,  что  парадигма  процедурного
>>> СМ> программирования  вообще  плохо  подходит для мультиплексирования,
>>> СМ> асинхронности   и   параллельности.   Можно   на   perl5  написать
>>> СМ> мультиплексирующий сервер? Можно конечно. Но если задуматься - это
>>> СМ> будет  реализация  уже  другой  парадигмы поверх "родной" для perl
>>> СМ> процедурной.  Поэтому  и не приживаются подобные проекты в широких
>>> СМ> массах, а приживается привычный prefork.
>>>
>>> СМ> Но для каждой задачи есть решение - есть и специфичные инструменты
>>> СМ> для  параллельных  вычислений.  Есть  вполне реальный Erlang, есть
>>> СМ> какой-то   удивительный   Oz  (и  говорят  на  нем  есть  реальные
>>> СМ> веб-проекты)  и  т.п. - в которых нужная "модель мира" заложена на
>>> СМ> базовом уровне.
>>>
>>> СМ> Я  это  к  тому, что можно конечно прогибать perl под какие угодно
>>> СМ> парадигмы  (или  наоборот  -  парадигмы  под perl) и реализовывать
>>> СМ> любые  идеи  -  но  я  бы  воспринимал  это  как  эксперименты или
>>> СМ> развлечение, я не как production работу.
>>>
>>> Мне тоже нравится, что перл очень стабильный. Но это не значит, что
>>> его не надо делать лучше :-)
>>>
>>> Не  знаю как тебе, но мне жалко простаивающего процессора. Как-то один
>>> продавец  рекламы  сказал  мне, что показ банера надо продать за любую
>>> цену,  потому  что  он есть прямо сейчас, а через минуту его не будет.
>>> Так  и  тут,  большинство процессоров простаивают и используются очень
>>> неэффективно.  И  что  меня  больше  всего  убивает, что причина этого
>>> всепланетарного  простоя  в  том,  что небольшая группа людей (человек
>>> 5-10    наверное),   разрабатывающих   gcc,   не   может   реализовать
>>> разбрасывание  на  несколько  корок  независимых кусков кода, а другая
>>> небольшая  группа  людей,  разрабатывающих Линух, Винду, Фрю и т.д. не
>>> даёт  им  для  этого быстрого интерфейса, утверждая, что распределение
>>> процессов  по  коркам - это задача шедуллера ОС, а не gcc, что в общем
>>> случае верно, но с увеличением числа корок нам приходится запускать на
>>> одном  сервере  кучу  процессов (как nginx запускает много worker-ов),
>>> дабы  они  могли  нормально утилизировать процессор, хоте можно был бы
>>> запустить один mysqld и он бы полностью съедал проц.
>>>
>>> --
>>>
>>> С уважением,
>>> Михаил Монашёв, SoftSearch.ru
>>> mailto:postmaster на softsearch.ru
>>> ICQ# 166233339
>>> http://michael.mindmix.ru/
>>> Без бэкапа по жизни.
>>>
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>>
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>>
>
>
> --
> С уважением,
> Анатолий Шарифулин.
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20081212/591b9920/attachment.html>