Синхронные вызовы Read/WriteFile при FILE_FLAG

← →
SPeller © (2010-01-18 06:07) [0]

Подскажите, чреваты ли последствиями синхронные вызовы Read/WriteFile на файле, открытом с FILE_FLAG_OVERLAPPED, когда параметр lpOverlapped = nil? Мсдн настоятельно рекомендует указывать структуру overlapped:

If hFile is opened with FILE_FLAG_OVERLAPPED, the lpOverlapped parameter must not be NULL

но при этом тут же оговаривается:

If hFile is created with FILE_FLAG_OVERLAPPED and lpOverlapped is NULL, the function can report incorrectly that the read operation is complete

Но мне и не нужно получать сигналы о завершении. В примере из мсдн синхронного клиент-сервера вставил FILE_FLAG_OVERLAPPED и в клиенте и на сервере - вроде всё работает как и прежде.

А нужно для того, чтобы писать в двусторонний пайп асинхронно, а читать из него синхронно. Т.е. разные потоки могут писать в пайп в произвольное время в произвольном порядке, пишут они все данные одним блоком, одной операцией WriteFile. А вот читать ответы с другой стороны этого же пайпа нужно синхронно. Читающий поток прочитает полученные пакеты и отдаст нужному потоку. С асинхронной записью и синхронным чтением вроде всё работает, но терзают сомнения, вдруг где-то грабли вылезут?

← →
Вариант (2010-01-18 06:54) [1]

> SPeller © (18.01.10 06:07)

> Подскажите, чреваты ли последствиями синхронные вызовы Read/WriteFile
> на файле, открытом с FILE_FLAG_OVERLAPPED, когда параметр
> lpOverlapped = nil?

Чреваты.

> А нужно для того, чтобы писать в двусторонний пайп асинхронно,
> а читать из него синхронно

Я так понимаю из контекста не анонимный пайп?

В этом случае - для того, что бы дождаться завершения операции ввода/ вывода на файле, открытом с FILE_FLAG_OVERLAPPED, сделай после операции ввода/вывода (с lpOverlapped <> nil и корректно заполненной) вызов GetOverlappedResult c bWait=true (получим как бы синхронный вызов).

← →
SPeller © (2010-01-18 07:41) [2]

А чем чревато, если не секрет?
Да, пайп именованный.

← →
Вариант (2010-01-18 09:20) [3]

> SPeller © (18.01.10 07:41) [2]

Да наверное тем, что пишет MSDN - а пишет он, что функция неверное сообщит об окончании работы - что это - у меня есть мнение, но не скажу что оно окончательно верное, а потому не буду интерпритировать.
А вот по факту, когда я сам как-то забыл дать структуру, а дал nil, то просто результат функции был false.

← →
Rouse_ © (2010-01-18 10:42) [4]

А смысл указывания флага FILE_FLAG_OVERLAPPED на читающей стороне, если там явно нужно читать синхронно?

← →
Игорь Шевченко © (2010-01-18 13:16) [5]

> синхронные вызовы Read/WriteFile на файле, открытом с FILE_FLAG_OVERLAPPED

Это нонсенс. Если файл открыт с флагом FILE_FLAG_OVERLAPPED, это уже подразумевает асинхронные операции

← →
SPeller © (2010-01-19 00:19) [6]

> А смысл указывания флага FILE_FLAG_OVERLAPPED на читающей
> стороне, если там явно нужно читать синхронно?

> Если файл открыт с флагом FILE_FLAG_OVERLAPPED, это уже
> подразумевает асинхронные операции

Читать нужно синхронно, а писать - асинхронно в один и тот же пайп, хэндл один, пакеты данных приходят и уходят не строго по очереди как в примерах, а в случайном порядке. Сначала попробовал как описал в сабже, но засомневался. Просто никогда с асинхронным режимом не работал, поэтому и вопросы.

Сейчас сделал через GetOverlappedResult(wait), всё работает, и идеологически вроде всё верно.

← →
Игорь Шевченко © (2010-01-19 00:48) [7]

> Читать нужно синхронно

rc := ReadFile (FPipe, inBuf, MAX_READ, bytesRead, @OverLapRd); if not rc then lastError := GetLastError; if lastError = ERROR_IO_PENDING then // Ожидаем завершения ввода-вывода WaitForSingleObject (OverLapRd.hEvent, INFINITE);

Самое что ни на есть синхронное чтение

я почти так же и сделал.
говорю же, никогда с этим не работал, поэтому возникли глупые вопросы :)

SPeller © (19.01.10 03:39) [8]

http://www.delphimaster.ru/articles/named_pipes/index.html

тут как раз синхронная работа через асинхронные вызовы

Спасибо за ссылочку!

Синхронные вызовы Read/WriteFile при FILE_FLAG_OVERLAPPED Найти похожие ветки