Комментарии 17
Я бы не стал так категорично называть вас тем самым прибором =)
Для меня статья была интересной и кое что разъяснила.
Для меня статья была интересной и кое что разъяснила.
Если и чайник, то основательно подготовленный, статья замечательна :)
Я принципиально не вижу ограничений чтоб опрашивать несколько сокетов последовательно и соответственно читать из первого, в котором есть данные. Такой подход приводит к большим накладным расходам (overhead) процессорного времени.man 3 select
хорошая статья.
в свое время перелопатил кучу материала, разбираясь в этих вещах.
в свое время перелопатил кучу материала, разбираясь в этих вещах.
>пока не допилят aio, я думаю
С aio надо преаллокэйтить буффер для каждого сокета. Так что давайте уж как-нибудь без aio :)
С aio надо преаллокэйтить буффер для каждого сокета. Так что давайте уж как-нибудь без aio :)
Видел статьи на тему того, что куча тредов с блокирующими сокетами может быть быстрее чем неблокирующие на epoll/kqueue, но как-то небыло времени вникать. Думаю, было бы полезно покопать и описать эту тему :)
Неактуально из-за оверхеда памяти на стэк каждому треду.
И евентовая модель удобнее для обслуживания кучи сокетов.
Эксперимент с динамическими стэками для gcc'шных язычков увидим в gcc4.6, но надо чтобы ещё все зависимые либы были скомпилированы с флажком -fsplit-stack.
И евентовая модель удобнее для обслуживания кучи сокетов.
Эксперимент с динамическими стэками для gcc'шных язычков увидим в gcc4.6, но надо чтобы ещё все зависимые либы были скомпилированы с флажком -fsplit-stack.
Можно сделать кучу дочерних процессов(тредов), в каждом из которых будет epoll. Должно получиться еще быстрее, хотя по памяти будет сильный оверхед.
Наверное имеет смысл так делать при количестве ядер больше одного и большого объема доступной RAM
Наверное имеет смысл так делать при количестве ядер больше одного и большого объема доступной RAM
Конечно быстрее, особенно на многопроцессорной машине. Но только до определенного предела — либо памяти при большом колличестве коннектов соожрет, либо просто тормозить будет из за необходимости ядру распределять ресурсы между кучей тредов/процессов…
во кстати: www.opennet.ru/base/dev/server_way.txt.html там и Игорь Сысоев отметился.
А все равно в этом деле Эрланг всех победит))
Пока только приглядываюсь к ФЯП. Не могли бы вы пару слов сказать чем они лучше в данном аспекте?
Спасибо
Спасибо
ФЯП в целом не знаю лучше ли, но конкретно Erlang благодаря своим микропроцессам и изначально продуманной отказоустойчивой распределенной архитектуре лучше. В 2-х словах: надежность, параллельность и масштабируемость из коробки.
Если подробнее — можете посмотреть мои комментарии последние вроде этого habrahabr.ru/blogs/erlang/111252/#comment_3552220, вообще последние статьи из блога habrahabr.ru/blogs/erlang/ Еще довольно неплохая статья
fprog.ru/2010/issue6/dmitry-demeshchuk-node.js-vs-erlang/ Есть доклад разработчика erlyvideo addconf.ru/event.sdf/ru/add_2010/authors/maximLapshin/154
Если подробнее — можете посмотреть мои комментарии последние вроде этого habrahabr.ru/blogs/erlang/111252/#comment_3552220, вообще последние статьи из блога habrahabr.ru/blogs/erlang/ Еще довольно неплохая статья
fprog.ru/2010/issue6/dmitry-demeshchuk-node.js-vs-erlang/ Есть доклад разработчика erlyvideo addconf.ru/event.sdf/ru/add_2010/authors/maximLapshin/154
Для дополнительного чтения по теме статья от вашего покорного слуги: habrahabr.ru/blogs/python/107237/
Благодарю. Как раз мой следующий шаг будет в написании асинхронного веб сервера и клиента на python. Можно еще отметить статью habrahabr.ru/blogs/python/87793/
Обязательно прочитаю статью как будет время
Обязательно прочитаю статью как будет время
В схеме мультиплексирования ошибка в макросе ошибки, вместо EINPROGESS должно быть EINPROGRESS(в процессе выполнения).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мультиплексированный ввод/вывод