2011/12/6 Denis F. Latypoff <latypoff@yandex.ru>

> 06.12.2011, 02:32, "Yaroslav" <yarosla@gmail.com>:
> > 2011/12/5 Igor Sysoev <igor@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.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru