feature request: sendfile management

[Alex Vorona]

MZ пишет:
> В пн, 22/10/2007 в 10:11 +0400, Igor Sysoev пишет:
>   
>> On Mon, Oct 22, 2007 at 09:41:23AM +0400, Andrey N. Oktyabrski wrote:
>>
>>     
>>> MZ wrote:
>>>       
>>>> man sendfile:
>>>>     The flags argument has one possible value: SF_NODISKIO.  This flag
>>>> causes any sendfile() call which would block on disk I/O to instead
>>>> return EBUSY.  Busy servers may benefit by transferring requests that
>>>> would block to a separate I/O worker thread.
>>>>
>>>> может стоит использовать эту фишку ?
>>>> если EBUSY, то отдавать самому без sendfile, а иначе пусть ядро отдает ?
>>>>         
>>> ano at shrek:~> uname -sr
>>> SunOS 5.10
>>> ano at shrek:~> man sendfile
>>> ...
>>> ssize_t sendfile(int out_fd, int in_fd, off_t  *off,  size_t len);
>>> ...
>>> Где тут "The flags argument"?
>>>       
> ман от FreeBSD
>   
>> sendfile - это вообще не стандратная вещь. Для Линуксе, например,
>> пришлось сделать специальную обработку 2G+ файлов для sendfile32().
>>     
> Я понимаю.
> Но тормозит ведь! Может и для фри  #ifdef поставить ? Я бы и сам сделал,
> но не занимаюсь плотно С - могу накосячить.
>
>   
простым #ifdef тут наврядли обойтись получится. На одном и том же файле  
в течение одного запроса sendfile()'ы  могут и блокироваться и не 
блокироваться, например в зависимости от загрузки дисков и/или от 
скорости канала к клиенту. Можно конечно упростить задачу, и, как только 
sendfile() заблокировался первый раз - продолжать отдавать файл через 
read/write. Насколько эта схема будет эффективной - вопрос второй.

Какие ещё могут быть варианты ухода nginx от блокировки на диске, 
забывая про AIO?