Всем привет!!!

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

Здравствуйте Digger, Вы писали:

D>Не ришал ли ктонибудь такой задачи: есть два потока, один в файл что-то пишет, а другой должен читать. Сразу скажу, что вывешиванием событий для синхронизации пользоваться нельзя, то есть считывание должно происходить по факту записи, причем запись пакетная, заголовок, а потом данные.

А почему именно файл? А если взять pipe или свою очередь написать?

По существу вопроса есть такой вариант: при записи файл должен изменяться , значит можно поймать уведомление от файловой системы. Глянь на FindFirstChangeNotification.

Здравствуйте Stanislav V. Zudin, Вы писали:

SVZ>А почему именно файл? А если взять pipe или свою очередь написать?

Ну вот так вот сложилось...

SVZ>По существу вопроса есть такой вариант: при записи файл должен изменяться , значит можно поймать уведомление от файловой системы. Глянь на FindFirstChangeNotification.

Все уведомления слишком запаздывают, в моем случае нужно, чтоб реакция была не позже чем 200 ms

Здравствуйте Digger, Вы писали:

D>Всем привет!!!

D>Не ришал ли ктонибудь такой задачи: есть два потока, один в файл что-то пишет, а другой должен читать. Сразу скажу, что вывешиванием событий для синхронизации пользоваться нельзя, то есть считывание должно происходить по факту записи, причем запись пакетная, заголовок, а потом данные.

А что, SendMessage после записи тоже нельзя

Здравствуйте Digger, Вы писали:

Есть предположение, что можно воспользоваться VirtualAlloc. flAllocationType
с флагом MEM_WRITE_WATCH позволит наблюдать за изменениями в области памяти.
Но на самом деле, если ты хорошенко все продумаешь, ты все приведешь до работы через MapFile. Который посуществу и работает, через VirtualAlloc.

Здравствуйте Vector, Вы писали:

V>А что, SendMessage после записи тоже нельзя

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

Здравствуйте whiteForest, Вы писали:

F>Есть предположение, что можно воспользоваться VirtualAlloc. flAllocationType
F> с флагом MEM_WRITE_WATCH позволит наблюдать за изменениями в области памяти.
F>Но на самом деле, если ты хорошенко все продумаешь, ты все приведешь до работы через MapFile. Который посуществу и работает, через VirtualAlloc.

Я об этом думал, но возникает проблема со считыванием из НЕИЗМЕНЯЕМОГО файла, тоесть если файл уже существует к моменту его считывания.

Здравствуйте Digger, Вы писали:

SVZ>>По существу вопроса есть такой вариант: при записи файл должен изменяться , значит можно поймать уведомление от файловой системы. Глянь на FindFirstChangeNotification.

D>Все уведомления слишком запаздывают, в моем случае нужно, чтоб реакция была не позже чем 200 ms

Уведомления запаздывают, даже если сделать FlushFileBuffers?

V>А что, SendMessage после записи тоже нельзя

D>В том-то и засада, что считывание и обработку данных нужно отделить от всего остольного (интерфейса), а то постепенно накапливает отстование

Если не хочешь SendMessage использовать, воспользуйся callback механизьмом. Вполне независимый подход.

Здравствуйте Stanislav V. Zudin, Вы писали:

SVZ>Уведомления запаздывают, даже если сделать FlushFileBuffers?

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

SVZ>Если не хочешь SendMessage использовать, воспользуйся callback механизьмом. Вполне независимый подход.

Не понял callback кого и откуда.

Вообщето идеальным решением было бы использование OVERLAPPED считывания, но на файлах, этот миханизм не работает (или я чего то не понял), кстати нет ни каких догадок пучему так странно сделали — в случае пайпов работает не так как в случае с файлами?

Здравствуйте Digger, Вы писали:

SVZ>>Уведомления запаздывают, даже если сделать FlushFileBuffers?
D>Можно попробовать, но такой метод сам по себе кривой, привлекать систему при синхнонизации в пределах одного процесса, это выглядит как-то странно.

Ну, если ты для записи в файл используешь WriteFile, то почему бы не вызвать FlushFileBuffers, раз уж система все равно привлечена

D>Не понял callback кого и откуда.

Под callback'ом я понимаю указатель на функцию, либо на объект, который передается твоему "писателю", чтобы тот вызвал эту функцию/метод объекта дабы уведомить "читателя". В общем СОМовские ConnectionPoints. Необходимая независимость читателя и писателя соблюдается.
А внутрях можно и SendMessage использовать.

D>Вообщето идеальным решением было бы использование OVERLAPPED считывания, но на файлах, этот миханизм не работает (или я чего то не понял), кстати нет ни каких догадок пучему так странно сделали — в случае пайпов работает не так как в случае с файлами?

Не понимаю, как тебе в данном случае может помочь асинхронность... Ты что, собираешься циклически перечитывать файл, пока какие-нибудь свежие данные не придут?

Здравствуйте Digger, Вы писали:

D>Вообщето идеальным решением было бы использование OVERLAPPED считывания, но на файлах, этот миханизм не работает

Работает.
Так же можно воспользаваться портами завершения ввода вывода.
Подробмости в книге "Програмирование серверных приложений", часть 1, глава 2.

Здравствуйте Владислав, Вы писали:

В>Работает.
В>Так же можно воспользаваться портами завершения ввода вывода.
В>Подробмости в книге "Програмирование серверных приложений", часть 1, глава 2.

А как работает, если вместо ожидания считывания 100 байтов возвращается ошибка (конец файла)?

Здравствуйте Stanislav V. Zudin, Вы писали:

SVZ>Ну, если ты для записи в файл используешь WriteFile, то почему бы не вызвать FlushFileBuffers, раз уж система все равно привлечена

Ж-), я име в виду ожидание увидомления

SVZ>Под callback'ом я понимаю указатель на функцию, либо на объект, который передается твоему "писателю", чтобы тот вызвал эту функцию/метод объекта дабы уведомить "читателя". В общем СОМовские ConnectionPoints. Необходимая независимость читателя и писателя соблюдается.

Спосибо за лекцию, у тебя талант! Фишка в том, чтоб "читатель" знал только имя файла...

SVZ>А внутрях можно и SendMessage использовать.

А можно и снаружи, но только нельзя.

SVZ>Не понимаю, как тебе в данном случае может помочь асинхронность... Ты что, собираешься циклически перечитывать файл, пока какие-нибудь свежие данные не придут?

Как, это как? Как всегда — читаеш заголовок, ждеш пока считаеться, из него узнаеш размер данных и его читаеш с ожиданием, и т.д.

Здравствуйте Digger, Вы писали:

D>А как работает, если вместо ожидания считывания 100 байтов возвращается ошибка (конец файла)?

Хм... Один поток асинхронно пишет в файл, другой ждёт когда операция записи завершится (OVERLAPPED::hEvent, структура OVERLAPPED разделяема между потоками, когда Event выставлен, второй поток считывает из структуры OVERLAPPED количество байт, которые были записаны, позиционируется на начало этой записанной информации, и пытается её прочитать.
Я правильно понимаю?
И при этом — ошибка: конец файла?