В общем, есть приложение, которое записывает данные в файлы(много их) асинхронно, время от времени оно выдает сообщение об ошибке: "The I/O operation has been aborted because of either a thread exit or an application request" и продолжает работать дальше...
К чему-бы это?

к отладчику?

я не могу это воспроизвести, это происходит после нескольких суток работы приложения, поэтому я и спрашиваю, что может вызвать подобную ошибку (GetLastError = 995)

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

Lazin
Может быть вызвано неправильной синхронизацией потоков. Это ошибка вроде означает что программа пытается прочитать из файла, который закрыт (или может заблокирован??).

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

файлы открываются в режиме FILE_SHARE_READ | FILE_SHARE_WRITE а так-же FILE_FLAG_OVERLAPPED
разные потоки могут вызывать WriteFile для одного и того-же файла, данные которые должны быть записаны, удаляются после того, как на порт завершения будет добавлен пакет завершения сигнализирующий о том, что все данные записаны

по-русски, 995 ошибка звучит так: "Операция ввода/вывода была прервана из-за завершения потока команд или по запросу приложения. "

Lazin, у тебя ни где не вызывается случайно CancelIO?
это по-моему, как раз второй случай - "...по запросу приложения"

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

Да
А кто выдает ошибку - твоя библиотека или кто то еще?

а принципе - да, если очередь не пуста, а поток завершается, то оставшиеся команды I/O теряются, но по идее, чтобы отловить эту ошибку нужен по крайней мере не полная асинхронная операция, ты используешь простой или расширенный интерфейс? WriteFile или WriteFileEx?

у меня есть два варианта возможного решения:
1. в Red/WriteFile а четвертый параметр передавать NULL (это в некотором роде подсказка оси, что в данный момент даже пытаться выполнять операцию не надо)
2. использовать расширенный интерфейс и ввести счетчик операций, тогда перед завершением потока можно убедиться, что очередь не пуста и подождать, если это не так:

а в callback'е завершения I/O, уменьшать этот счетчик:

тогда перед самой чтением/записью, этот счетчик увеличить:


Добавлено через 6 минут и 46 секунд
можно синхронный счетчик использовать InterlockedIncrement/Decrement

ошибку я получаю в своей библиотеке
все работает примерно так:

это что-то вроде псевдокода, но суть должна быть понятна

Добавлено @ 14:42
зы
я там использую порт завершения

Добавлено @ 14:48
я пока вижу такое решение: не вызывать ф-ю WriteFile из потока пользователя вообще, вместо этого вызывать PostQueuedCompletionStatus и передавать туда данные, приняв которые, мой поток начал-бы выгребать данные из очереди и писать их в файл

Это сообщение отредактировал(а) Lazin - 16.4.2009, 14:58

а что мешает сначала заполнить очередь,
а потом подождать завершения всех операций?

у тебя получается так, что скорость передачи данных в порт напрямую зависит от времени ожидания GetQueuedCompletionStatus
и практически не зависит от скорости поступления данных (не используется разрешающая способность самой очереди ввода/вывода)

попробуй разделить:
если есть данные в очереди - пиши их в порт
кончились - жди завершения операций
появились - снова пиши и т.д.

а принудительно уходи в ожидание только при отказе WriteFile, когда квота заканчивается

мне нужно, что-бы даннве по возможности не накапливались в памяти

я возможно плохо все описал, попробую исправиться)
у меня есть очередь, очередь состоит из буферов фикс. размера, скажем, 64кб
пользовательское приложение вызывает ф-ю моей библиотеки, эта ф-я дописывает данные в конец последнего буфера в очереди, если его нет, то она его создает, далее, если в данные момент нет не завершенных операций записи в файл, она начинает новую, вызывая WriteFile. Соответственно в ф-ю WriteFile передаются все 64kb (первый в очереди буфер).
В этот момент данные еще не записаны, если пользовательское приложение снова вызовет мою ф-ю, то данные будут добавлены в буфер, но ф-я WriteFile вызвана не будет, так-как предидущая операция записи еще не завершена, считается что он "занят".
Рабочий поток моей библиотеки ждет на порте завершения, и когда завершается очередная операция записи он освобождает 64кб буфер, а затем пытается извлечь из очереди следующий буфер и начать записывать его. 
Пока есть незавершенные операции записи (это контролируется) файл не будет закрыт. Единственное что у меня может пойти не так, это поток пользовательского приложения может начать операцию записи(вызвав WriteFile) и сразу завершиться (вполне вероятно что даже аварийно, вызвав ExitThread или TerminateThread...

Это сообщение отредактировал(а) Lazin - 16.4.2009, 22:57

нет, я все понял, наверное, сам неверно выразился, смешав 2 очереди )

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

мне кажется, что очередь, которую ты строишь дополнительно - лишняя нагрузка на my_class :: function,
если ты хотел отвязаться от ожидания завершения записи на диск при вызове function, то ты от него избавился, но прибавил в нагрузку практически тот же самый вес, формируя дополнительную очередь

тут достаточно просто асинхронно писать в файл, учитывая общее число байт (чтобы не выйти из потока преждевременно)

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