Re: fprintf && write

From

Igor Sysoev ()

To

Boris Rudakov ()

Date

2003-06-07T18:00:36Z

Area

CARBON.COPY

 * Forwarded from area 'RU.UNIX.PROG'
From: Igor Sysoev <is@rambler-co.ru>

Boris Rudakov <Boris.Rudakov@p4.f9.n5054.z2.fidonet.org> wrote:

> У CreateFile есть два флага на предмет отрубания буфферизации (флагов
> управления буфферизацией больше, но это уже другая история):
> 
> * FILE_FLAG_NO_BUFFERING - это самая зверская штука и требует чтобы чтение
> производилось блоками строго кратными размеру сектора и с позиции строго равной
> началу определенного сектора. Если что не так - система посылает лесом.
> 
> В юниксах я такого не нашел, хотя близкие по смыслу вещи вроде замечал...

O_DIRECT, но есть не везде. Но тут нужно не забывать, что Windows -
это всего три платформы - 9X, NT и CE, которые полностью контролируются одной
фирмой в то время, как юниксы - это десяток фирм и несколько опенсоурс
разработок. Но даже в случае трёх платформ Майкрософт умудрился сделать
много несовместимостей в совершенно непринципиальных случаях, типа
того, что NT в какой-либо функции разрешает передачу NULL в параметре,
а 9X - нет.

> * FILE_FLAG_WRITE_THROUGH - о котором речь и идет. В этом режиме чтение
> буфферизуется, НО запись происходит сначала в кеш, а потом СРАЗУ ЖЕ
> производится сброс на диск. Понятно что сброс посекторный. Но и режим этот
> нужен только для надежного ведения логов (в первую очередь - дебажных) когда не
> софтина может накрыться тазом в любой моммент (буффера ядра в любом случае
> сбросятся при закрытии файла), а есть риск хардверного сбоя или сбоя по питалу.

На этот случай есть fsync(), аналог FlushFileBuffers(). Это, конечно,
дополнительный сисколл, но по сравнению с собственно записью на диск,
его оверхед копеечный.

>  BR>> именно внутренние буффера ядра.  Этот режим сильно тормозит, но
>  BR>> крайне полезен для ведения дебажных логов. Как это делается ?
>  DS>      стандарта нет.  во фрюхе, например, открываешь файл с флагом
>  DS> O_DIRECT и кэширование *минимизируется*, полностью его отключить
>  DS> нельзя по описанным выше причинам.
> 
> Ыххххх...
> 
> Я, когда начал интересоваться портом софта в юниксы, спрашивал в этой эхе нет
> ли чего аналогичного MSDN, где есть много обзорной вступительной информации
> (иногда даже структурированной, хех). Очень многое из рекоммендованного мне я
> прочитал, но не оставляет ощущение некоторой разрозненности / неполноты
> информации... Каждый кусок описан хорошо, но с общеобзорной литературой хуже :(

Лучшая книжка по программированию под юниксы, на мой взгляд, это "Advanced
Programming in the UNIX Environment", http://www.kohala.com/start/apue.html
Она, конечно, стоит денег. На русском, а стало быть, в более дешёвом
варианте её пока нету. Опять же можно почитать книжку Робачевского,
хотя там, конечно, далеко не уровень Стивенса, но для общеобзорности
вполне сойдёт.

Я думаю, что MSDN ты стал читать после того, как почитал, к примеру,
Петзольда или Рихтера и поэтому просто не замечал разрозненности и неполноты
MSDN. У меня, например, при чтении MSDN возникает много вопросов
(правда, не общеобзорных), ответы на которые приходится искать или в Гугле,
или ставить эксперименты.

Что ещё меня убивает во всей виндовой литературе, в том числе и в MSDN,
так это практически повсеместное игнорирование ошибок. Такое ощущение,
что их не бывает. В юниксовых манах есть секция с перечислением ошибок,
которые может вернуть данный сисколл или функция с описанием того, в чём
именно заключается ошибка.
Я как-то потратил пару часов, чтобы понять почему WSASend() возвращает
WSAEINVAL в то время, как все параметры правильные. Оказалось, WSABUF
должны быть выровнены на 4 байта. Хоть бы где про это было написано.
Нашёл в одном сообщении в Гуглгруппс.


-- 
Игорь Сысоев
http://sysoev.ru
--- ifmail v.2.15dev5
 * Origin: Rambler Office news site (2:5020/400)