fprintf && write (resolved)

From

Andrey Melnikov (2:5030/1340.116)

To

Valentin Nechayev ()

Date

2003-06-05T21:33:40Z

Area

RU.UNIX.PROG

                               Hello Valentin!

 05 Jun 03 10:27, Valentin Nechayev wrote to Lev Walkin:
 VN> From: Valentin Nechayev <netch@segfault.kiev.ua>
 >>>> Lev Walkin wrote:
 >>> 1. Получить засыпание при вызове fprintf(...) где-то в ядре на
 >>> write(..) на очень большое время, что увы неприемлимо. 2.
 >>> Использовать
 >>> alarm(time), write()/fprintf(), alarm(0); - я получу 3 системных
 >>> вызова.
 LW>> а попробуй так:
 LW>> 1. при открытии дескриптора переводи его в non-blocking mode.
 LW>> 2. В подобных твоему участках кода делай _сначала_ write(), а уж
 LW>> потом, если write() вернул -1/EAGAIN, то select:

 VN> Непонятно, нахрена тут select() вообще.
    Таймаут. Дабы если у нас write() == -1 и errno == EAGAIN подождать пока reader всосет то, что есть у ядра в буферах. Ибо есть в нашей стране чудаки, которым дали ручку "зарезать icmp" - ну они и зарезали все, что можно. reader умер, а icmp что host/port/net недоступны - непришло.

 VN> Если объект неблокирующий, то просто писать пока буфер не
 VN> опустошится, write() не скажет EAGAIN, или ошибка какая не вылезет.
 VN> select() нужен или для гарантии неблокируемости последующего write()
 VN> с O_NONBLOCK, или для выбора, а что же делать следующим.
 VN> Блокируемость убрали, точки выбора нет - select() не нужен.

    Вообщем - проблема найдена и удавлена. Именно способом который посоветовал Lev Walkin.  Количество селектов упало в разы, скорость вернулась к нормальной (той, которая была до модификации).

Всем спасибо. :)

PS: А тест, которым мерялась скорость - оказался слишком синтетическим. Ибо скорость я мерял через пайпы. Для той-же кривой конструкции, но через tcp по loopbackу - падение скорости было порядка 3-5 секунд от ожидаемого.

     Andrey aka TEMHOTA-RIPN
--- GoldED+/LNX 1.1.4.7
 * Origin: Powered by SlackWare Linux (2:5030/1340.116)