Re: NXWEB и nginx

[Denis F. Latypoff]

06.12.2011, 08:10, "Yaroslav" <yarosla at gmail.com>:
> 2011/12/6 Denis F. Latypoff <latypoff at yandex.ru>
>> 06.12.2011, 02:32, "Yaroslav" <yarosla at gmail.com>:
>>> 2011/12/5 Igor Sysoev <igor at sysoev.ru>
>>>> Не факт, что edge triggered в том чистом виде, как он реализован в epoll
>>>> лучше level triggered. Например, если на момент добавления сокета в epoll
>>>> данные уже есть в сокете, то edge triggered epoll про них не раскажет.
>>>> Приходится делать лишний read после добавления. Кроме того, есть и просто
>>>> ошибка реализации edge triggered, когда нужно делать read до получения
>>>> EAGAIN, иначе можно пропустить EOF.
>>>>
>>>> А вот EV_CLEAR в kqueue сделан явно с применением мозга.
>>> Автор libev тоже не очень лестно высказывается насчет epoll. В частности он пишет об ошибках в его работе:
>>>> The epoll mechanism deserves honorable mention as the most misdesigned of the more advanced event mechanisms: mere annoyances include silently dropping file descriptors, requiring a system call per change per file descriptor (and unnecessary guessing of parameters), problems with dup, returning before the timeout value, resulting in additional iterations (and only giving 5ms accuracy while select on the same platform gives 0.1ms) and so on. Epoll is also notoriously buggy - embedding epoll fds should work, but of course doesn't, and epoll just loves to report events for totally different file descriptors (even already closed ones, so one cannot even remove them from the set) than registered in the set (especially on SMP systems). Epoll also erroneously rounds down timeouts, but gives you no way to know when and by how much, so sometimes you have to busy-wait because epoll returns immediately despite a nonzero timeout. And last not least, it also refuses to work with some file descriptors which work perfectly fine with select (files, many character devices...).
>>> Хотелось бы узнать по Вашему опыту, такие проблемы действительно имеют место? Или может они исправлены в более свежих версиях ядра?
>>>
>>
>> Да дело даже не в том, что еполл на каких-то ядрах недозапилен,
>> а в том, что libev by design таков, что не позволяет использовать
>> нестандартные фичи event-движков ядра. То есть если во фре,
>> например, можно узнать об EOF прямо из kqueue, то с libev на той
>> же фре - только через дополнительный read, который вернет -1
>> и установит errno в EAGAIN. libev использует только базовые
>> механизмы, в то время как nginx все прелести event-движков
>> с целью уменьшения кол-ва передергивания контекста.
> Про libev я все понял. Знал про отсутствие поддержки ET изначально. Но мой вопрос сейчас не про libev, а про epoll. Понимаю также, что kqueue более продвинут, но у меня Linux.
>

А насчет кривости ядер - не парься, это все равно не твоя вина.
В этом плане в libev все что, можно - за'workaround'ено

-- 
br, Denis F. Latypoff.