Overlapped IO

← →
Rad © (2003-12-23 03:07) [0]

Пытаюсь асинхронно писать сообщения в текстовый лог:
var s: string; procedure WriteLogFile(hFile: THandle; var ovl: OVERLAPPED; sLogLn: string); var i: cardinal; begin s:= sLogLn + #13#10; ovl.Offset:= GetFileSize(hFile, @ovl.OffsetHigh); WriteFile(hFile, s, Length(s), i, @ovl); SetFilePointer(hFile, ovl.InternalHigh, nil, FILE_CURRENT); end;
hFile открыт с FILE_FLAG_OVERLAPPED, результат записи не интересует, поэтому ovl.hEvent:= 0;
В файле оказывается чушь.
Если сделать примерно так:
WriteFileEx(hFile, s, Length(s), ovl, nil); - то весь валится весь процесс (в упрощенном тестовом примере всё работает как раз с WriteFileEx, а чушь пишется с WriteFile); но при nil-указателе на Callback-функцию (FileIOCompletionRoutine) это некоторым образом логично :)
Если короче, то я запутался с этим асинхронным выводом :)
Никто не может кинуть ссылкой, где можно почитать какой-никакой примерчик на эту тему (но не про работу с COM-портами)?

← →
SPeller © (2003-12-23 04:00) [1]

передавай в функцию WriteFile s[1] вместо s.

← →
Rad © (2003-12-23 04:28) [2]

SPeller © (23.12.03 04:00) [1]
Спасибо!!!
Хм... А как этот приём понимать? :)

← →
Polevi © (2003-12-23 09:21) [3]

PChar(s)^

← →
y-soft © (2003-12-23 15:12) [4]

>Rad © (23.12.03 03:07)

А Вы уверены, что в момент вызова SetFilePointer поле ovl.InternalHigh показывает верное значение? Все-таки не мешало бы ожидать окончания записи, иногда ведь WriteFile завершется с ошибкой 997 ERROR_IO_COMPLETE и в InternalHigh в этом случае количество записанных байт не заносится до фактического окончания записи. Не мешало бы для гарантии использовать WaitXXX или GetOverlappedResult с установленным флагом ожидания до вызова SetFilePointer, иначе перекрытый ввод теряет смысл...

y-soft © (23.12.03 15:12) [4]
прям вот на Вы... :)

> уверены, что в момент вызова SetFilePointer поле ovl.InternalHigh показывает верное значение?
мда, не уверен.
а если
SetFilePointer(hFile, Length(s), nil, FILE_CURRENT)?

> использовать WaitXXX или GetOverlappedResult с установленным флагом ожидания до вызова SetFilePointer, иначе перекрытый ввод теряет смысл
Вот ждать-то как раз и не хотелось бы: типа, отправил запрос на запись и забыл, записалось или нет - не столь важно.

>Rad © (23.12.03 15:52) [5]
Вот ждать-то как раз и не хотелось бы: типа, отправил запрос на запись и забыл, записалось или нет - не столь важно.

Но тогда как быть уверенным, что указатель перемещается правильно?

Перекрытый ввод/вывод обычно используют только в приложениях, где больше одного потока и одновременно производится запись/чтение в несколько файловых объектов (или в один одновременно), иначе выгоды от него никакой, т.к. все равно приходится ждать завершения операции, разве что не потребляет процессорное время в момент ожидания :)

Вот и делают так, что один поток осуществляет взаимодействие с пользователем и контролирует второй поток, а второй - непосредственно дает команды на ввод/вывод в файловые объекты и ждет их завершения обычно с помощью WaitForMultipleObjects. В этом случае получается очень экономно и надежно, т.к. не нужно использовать объекты синхронизации внутри второго потока для разделения доступа к файлам...

Overlapped IO Найти похожие ветки