Неблокируемые операции с файлами

Блокируемость у файловых дескрипторов точно такая же, что и у сокетов.

Спасибо!

Т.е. получается, что если все приложение написать на неблокируемых дескрипторах с использованием механизма а-ля select (poll, epoll...), то необходимости в использовании тредов вообще отпадет?

2UncleAndy (14.09.2005 18:59:25):

А при чем тут треды?

И зачем нужны НЕблокирующие дескрипторы, если используется select()?

Я это все выясняю как раз в контексте необходимости использования трэдов в сетевом сервере, в котором будет активная работа с файлами (грубо говоря, в файл-сервере).

А необходимость использование неблокирующихся дескрипторов с select() я вижу в том, что-бы при операциях read/write читалось/писалось столько данных, сколько возможно в данный момент, а не столько сколько нужно, но с блокировкой.

Возможно, что я не совсем понимаю цель использования неблокируемых сокетов, но мне кажеться, что для исключения блокировок даже в варианте с select лучше использовать их. Или тут все-таки есть подводные камни?

есть мнение что если fd связан с файлом на винте то с него нельзя снять блокируемость.

думаю тебе сильно могут помочь треды + man sendfile

Ну, это-то понятно. Т.е. если есть работа с файлами без трэдов все-таки не обойтись?

>Ну, это-то понятно. Т.е. если есть работа с файлами без трэдов все-таки не обойтись?

ты меня неправильно понял. обойтись можно и даже при этом получить неплохие результаты.

просто sendfile я считаю наиболее еффективна именно в связке с тредами

а ещё существует aio - асинхронный ввод вывод. можешь ещё в эту сторону посмотреть. там кажись точно треды не понадобятся но может возрасти количество гейтов в ядро.

Насколько я помню - для поддержки AIO надо патчить ядро. Такой вариант не подойдет. Лучше уж с трэдами.

> ты меня неправильно понял. обойтись можно и даже при этом получить неплохие результаты.

Что-то я не понимаю. А как-же тогда обойтись без трэдов в операциях с файлами?

Вообще, я планирую использовать библиотеку libevent. Если работу с хэндлами файлов организовать через нее - это поможет обойтись без трэдов?

>Насколько я помню - для поддержки AIO надо патчить ядро.

у меня такой информации нету

>> ты меня неправильно понял. обойтись можно и даже при этом получить неплохие результаты.

>Что-то я не понимаю. А как-же тогда обойтись без трэдов в операциях с файлами?

select() делаеш только на сокетах()

а потом поочереди для каждого дескриптора делаеш read() с винта send() в сокет или тот же sendfile дёргаеш. если настроиш сокеты так чтобы select возвращал ready for out только если в буфере свободно например >= 512 байт то отдавая каждым send-om OR sendfile-om именно 512 байт получиш весьма сносную скорость. весь ввод/вывод естественно неблокируемый

> если настроиш сокеты так чтобы select возвращал ready for out только если в буфере свободно например >= 512 байт

Очень интересно! А можно поподробнее каким образом сокет для этого настривается?

Я так понимаю, что и ввод можно настроить на то, что-бы select возвращал ready for in только если готово определенное количество данных в буфере?

Хотя, с другой стороны, на ввод это лучше не настраивать, т.к. при неполном заполнении буфера будут задержки. Так?

cvv

> есть мнение что если fd связан с файлом на винте то с него нельзя снять блокируемость.

Чисто академическое замечание, ибо read() из файла, один хрен, никогда не уснет.

А write в файл?

> А write в файл?

Тем более.

>> есть мнение что если fd связан с файлом на винте то с него нельзя снять блокируемость.

>Чисто академическое замечание, ибо read() из файла, один хрен, никогда не уснет.

насколько я понял man то в линуксе нет понятия блокируемый/неблокируемый ввод/вывод для регулярных файлов. а то что есть мне всётаки больше напоминает блокируемый ввод/вывод.

2UncleAndy:

> Возможно, что я не совсем понимаю цель использования неблокируемых сокетов, но мне кажеться, что для исключения блокировок даже в варианте с select лучше использовать их.

Абсолютно бессмысленно.

Существует _очень_ мало случаев, когда нужны неблокирующие дескрипторы. При использовании select() я только один такой случай могу навскидку сказать: организация неблокирующего connect()'а на сокете.

cvv (15.09.2005 14:31:13):

> а то что есть мне всётаки больше напоминает блокируемый ввод/вывод.

Ну, флажок-то снять/поставить на дескриптор можно! А блокировки никогда не будет, вне зависимости от флажка.

2UncleAndy:

Мое персональное мнение, что тредов надо всячески избегать. Единственное оправданное применение тредов -- реализация алгоритмов с динамической масштабируемостью, когда число доступных процессов может изменяться в процессе работы программы.

s/число доступных процессов/число доступных процессоРОв/

> Существует _очень_ мало случаев, когда нужны неблокирующие дескрипторы. При использовании select() я только один такой случай могу навскидку сказать: организация неблокирующего connect()'а на сокете.

+ обычный accept() во избежании неприятностей :)

// wbr

>Мое персональное мнение, что тредов надо всячески избегать.

поддерживаю, но ради одного sendfile я бы не делал fork. я думаю что мы больше потеряем на сам форк чем выиграем от sendfile.

klalafuda (15.09.2005 15:01:13):

> + обычный accept() во избежании неприятностей :)

Да, про него забыл :-)

Может, еще что есть. Но таких случаев мало.

2cvv (15.09.2005 15:04:30):

> ...ради одного sendfile я бы не делал fork.

sendfile -- непортабильная линукс-фича, потому mustdie (за редкими исключениями)

> ...думаю что мы больше потеряем на сам форк чем выиграем от sendfile.

pool спасет отца русской демократии.

> Да, про него забыл :-) Может, еще что есть. Но таких случаев мало.

ну как сказать.. не забывайте, что читать/писать можно не только из сокетов. можно, например, из файла устройства. и как конкретный драйвер отреагирует на недополнение буффера в read() для блокируемого дескриптора - это как Бог на душу положит. может вернуть меньшее количество байт, а может и заблокировать до полного заполнения буффера и в обоих случаях в принципе будет прав. а вот если стоит O_NONBLOCK а он все равно блокирует процесс - это уже скорее косяк драйвера.

// wbr