Мультиплексированный ввод/вывод

[@Agent_J]

Я бы не стал так категорично называть вас тем самым прибором =)
Для меня статья была интересной и кое что разъяснила.

[@rpeMJIuH]

Если и чайник, то основательно подготовленный, статья замечательна :)

[@kekekeks]

Я принципиально не вижу ограничений чтоб опрашивать несколько сокетов последовательно и соответственно читать из первого, в котором есть данные. Такой подход приводит к большим накладным расходам (overhead) процессорного времени.

man 3 select

[@kekekeks]

Извиняюсь, не дочитал.

[@pavlick]

хорошая статья.
в свое время перелопатил кучу материала, разбираясь в этих вещах.

[@nuit]

>пока не допилят aio, я думаю
С aio надо преаллокэйтить буффер для каждого сокета. Так что давайте уж как-нибудь без aio :)

[@saterenko]

Видел статьи на тему того, что куча тредов с блокирующими сокетами может быть быстрее чем неблокирующие на epoll/kqueue, но как-то небыло времени вникать. Думаю, было бы полезно покопать и описать эту тему :)

[@nuit]

Неактуально из-за оверхеда памяти на стэк каждому треду.
И евентовая модель удобнее для обслуживания кучи сокетов.

Эксперимент с динамическими стэками для gcc'шных язычков увидим в gcc4.6, но надо чтобы ещё все зависимые либы были скомпилированы с флажком -fsplit-stack.

[@Voltt]

Можно сделать кучу дочерних процессов(тредов), в каждом из которых будет epoll. Должно получиться еще быстрее, хотя по памяти будет сильный оверхед.
Наверное имеет смысл так делать при количестве ядер больше одного и большого объема доступной RAM

[@seriyPS]

Конечно быстрее, особенно на многопроцессорной машине. Но только до определенного предела — либо памяти при большом колличестве коннектов соожрет, либо просто тормозить будет из за необходимости ядру распределять ресурсы между кучей тредов/процессов…

[@seriyPS]

во кстати: www.opennet.ru/base/dev/server_way.txt.html там и Игорь Сысоев отметился.

[@seriyPS]

А все равно в этом деле Эрланг всех победит))

[@Voltt]

Пока только приглядываюсь к ФЯП. Не могли бы вы пару слов сказать чем они лучше в данном аспекте?
Спасибо

[@seriyPS]

ФЯП в целом не знаю лучше ли, но конкретно 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

[@aml]

Для дополнительного чтения по теме статья от вашего покорного слуги: habrahabr.ru/blogs/python/107237/

[@Voltt]

Благодарю. Как раз мой следующий шаг будет в написании асинхронного веб сервера и клиента на python. Можно еще отметить статью habrahabr.ru/blogs/python/87793/
Обязательно прочитаю статью как будет время

[@sudden_death]

В схеме мультиплексирования ошибка в макросе ошибки, вместо EINPROGESS должно быть EINPROGRESS(в процессе выполнения).