ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Несколько непонят ностей по nginx



Igor Sysoev пишет:
Дело в том, что lighttpd не использует EPOLLET, а nginx - использует.
Когда патч в ядре ограничивает объём передаваемых данных, то происходит
следующее - EPOLLET фиксирует состояние, что буфер свободен, об этом
сообщается приоложению (nginx'у), он делает sendfile. sendfile быстро
передаёт ограниченный объём, буфер по-видимому после этого полностью
свободный и новое событие не приходит.
модифицировал немного патч
-  res=*((int *)(&(sbuff[0])));
+  res=104857600;

в результате имею затыкающийся после 100м-вого sendfile()'а nginx. Буфер сокета выше 1М не поднимался. Подозреваю, что любое значение count у sendfile(), меньшее оставшегося неотосланного количества байт в файле, но приводящее к отдаче count байтов за один sendfile(), вызовет затык - не приходит событие(передано ровно запрошенное количество байт, а не меньше). В случае настроящего неблокирующегося sendfile() событие должно было бы прийти :) Похожая ситуация и с rtsig. С poll и select всё работает как и ожидалось.


для себя цитата из man epoll
The suggested way to use epoll as an Edge Triggered ( EPOLLET ) interface is below, and possible pitfalls to avoid follow.
   i     with non-blocking file descriptors
ii by going to wait for an event only after read(2) or write(2) return EAGAIN

вот как раз и получаем что при полном sendfile не имеем EAGAIN и не имеем события.



 




Copyright © Lexa Software, 1996-2009.