Re: NXWEB и nginx

[Denis F. Latypoff <latypoff@xxxxxxxxx>]

06.12.2011, 08:10, "Yaroslav" <yarosla@xxxxxxxxx>:
> 2011/12/6 Denis F. Latypoff <latypoff@xxxxxxxxx>
>> 06.12.2011, 02:32, "Yaroslav" <yarosla@xxxxxxxxx>:
>>> 2011/12/5 Igor Sysoev <igor@xxxxxxxxx>
>>>> Не факт, что 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.
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru