Сообщение Re[8]: Как синхронизировать PFLT_POST_OPERATION_CALLBACK и п от 16.09.2018 21:20
Изменено 16.09.2018 21:21 LimyKurn
Re[8]: Как синхронизировать PFLT_POST_OPERATION_CALLBACK и п
Здравствуйте, okman, Вы писали:
O>Здравствуйте, LimyKurn, Вы писали:
LK>>Спасибо за verifier, а вот по синхронизации надо либо что-то делать, либо все-таки счесть данную архитектуру чем-то ужасным
O>Если задача заключается в том, чтобы собирать какие-то данные на post operation callback и записывать в файл,
O>то вряд ли есть что-то лучше, чем отдельный поток, который это делает. Не вижу резона гонять эти данные в user mode и
O>писать в файл оттуда, это никаких выгод не даст, получится только лишнее усложнение на ровном месте.
O>Очередь можно сделать на базе linked list и засинхронизировать доступ к ней, как я уже писал, через спинлоки.
O>Рабочий поток будет ждать (KeWaitForXxx) на событии и при его сигналинге выгребать данные из очереди и сбрасывать их на диск.
O>То же самое делать можно и по таймауту (например, когда KeWaitForXxx вернула STATUS_TIMEOUT).
LK>>А если перенести логирование в минифильтры, то это гемор поменьше, но придется его оптимизировать по быстродействию, что ли, к тому же логирование создает файл — от рекурсии защищаться придется).
O>Там рекурсии неоткуда возникнуть.
LK>>Но и спинлоки как вариант "что-то делать" — не нравятся.
O>Почему?
Ты только сейчас появился, а у меня дедлайн завтра часов в 11) Хотя посплю всего 2 часа, но все равно похоже придется временно оставить вопрос с этой проблемой и заняться другими моментами драйвера собственно которые меня просили сделать. Ну или применить InterlockedExchange (хочу применить в рабочем потоке призамене указателя, а в каллбаках просто ничего не менять — там же нет ни очистки, ни выделения памяти. Какие проблемы?)
А спинлоки не нравятся тем, что в 24 мксек можно не уложиться из-за тормозов процессора тех же — и будет БСОД.
O>Здравствуйте, LimyKurn, Вы писали:
LK>>Спасибо за verifier, а вот по синхронизации надо либо что-то делать, либо все-таки счесть данную архитектуру чем-то ужасным
O>Если задача заключается в том, чтобы собирать какие-то данные на post operation callback и записывать в файл,
O>то вряд ли есть что-то лучше, чем отдельный поток, который это делает. Не вижу резона гонять эти данные в user mode и
O>писать в файл оттуда, это никаких выгод не даст, получится только лишнее усложнение на ровном месте.
O>Очередь можно сделать на базе linked list и засинхронизировать доступ к ней, как я уже писал, через спинлоки.
O>Рабочий поток будет ждать (KeWaitForXxx) на событии и при его сигналинге выгребать данные из очереди и сбрасывать их на диск.
O>То же самое делать можно и по таймауту (например, когда KeWaitForXxx вернула STATUS_TIMEOUT).
LK>>А если перенести логирование в минифильтры, то это гемор поменьше, но придется его оптимизировать по быстродействию, что ли, к тому же логирование создает файл — от рекурсии защищаться придется).
O>Там рекурсии неоткуда возникнуть.
LK>>Но и спинлоки как вариант "что-то делать" — не нравятся.
O>Почему?
Ты только сейчас появился, а у меня дедлайн завтра часов в 11) Хотя посплю всего 2 часа, но все равно похоже придется временно оставить вопрос с этой проблемой и заняться другими моментами драйвера собственно которые меня просили сделать. Ну или применить InterlockedExchange (хочу применить в рабочем потоке призамене указателя, а в каллбаках просто ничего не менять — там же нет ни очистки, ни выделения памяти. Какие проблемы?)
А спинлоки не нравятся тем, что в 24 мксек можно не уложиться из-за тормозов процессора тех же — и будет БСОД.
Re[8]: Как синхронизировать PFLT_POST_OPERATION_CALLBACK и п
Здравствуйте, okman, Вы писали:
O>Здравствуйте, LimyKurn, Вы писали:
LK>>Спасибо за verifier, а вот по синхронизации надо либо что-то делать, либо все-таки счесть данную архитектуру чем-то ужасным
O>Если задача заключается в том, чтобы собирать какие-то данные на post operation callback и записывать в файл,
O>то вряд ли есть что-то лучше, чем отдельный поток, который это делает. Не вижу резона гонять эти данные в user mode и
O>писать в файл оттуда, это никаких выгод не даст, получится только лишнее усложнение на ровном месте.
O>Очередь можно сделать на базе linked list и засинхронизировать доступ к ней, как я уже писал, через спинлоки.
O>Рабочий поток будет ждать (KeWaitForXxx) на событии и при его сигналинге выгребать данные из очереди и сбрасывать их на диск.
O>То же самое делать можно и по таймауту (например, когда KeWaitForXxx вернула STATUS_TIMEOUT).
LK>>А если перенести логирование в минифильтры, то это гемор поменьше, но придется его оптимизировать по быстродействию, что ли, к тому же логирование создает файл — от рекурсии защищаться придется).
O>Там рекурсии неоткуда возникнуть.
LK>>Но и спинлоки как вариант "что-то делать" — не нравятся.
O>Почему?
Ты только сейчас появился, а у меня дедлайн послезавтра) Хотя посплю всего 2 часа, но все равно похоже придется временно оставить вопрос с этой проблемой и заняться другими моментами драйвера собственно которые меня просили сделать. Ну или применить InterlockedExchange (хочу применить в рабочем потоке призамене указателя, а в каллбаках просто ничего не менять — там же нет ни очистки, ни выделения памяти. Какие проблемы?)
А спинлоки не нравятся тем, что в 24 мксек можно не уложиться из-за тормозов процессора тех же — и будет БСОД.
O>Здравствуйте, LimyKurn, Вы писали:
LK>>Спасибо за verifier, а вот по синхронизации надо либо что-то делать, либо все-таки счесть данную архитектуру чем-то ужасным
O>Если задача заключается в том, чтобы собирать какие-то данные на post operation callback и записывать в файл,
O>то вряд ли есть что-то лучше, чем отдельный поток, который это делает. Не вижу резона гонять эти данные в user mode и
O>писать в файл оттуда, это никаких выгод не даст, получится только лишнее усложнение на ровном месте.
O>Очередь можно сделать на базе linked list и засинхронизировать доступ к ней, как я уже писал, через спинлоки.
O>Рабочий поток будет ждать (KeWaitForXxx) на событии и при его сигналинге выгребать данные из очереди и сбрасывать их на диск.
O>То же самое делать можно и по таймауту (например, когда KeWaitForXxx вернула STATUS_TIMEOUT).
LK>>А если перенести логирование в минифильтры, то это гемор поменьше, но придется его оптимизировать по быстродействию, что ли, к тому же логирование создает файл — от рекурсии защищаться придется).
O>Там рекурсии неоткуда возникнуть.
LK>>Но и спинлоки как вариант "что-то делать" — не нравятся.
O>Почему?
Ты только сейчас появился, а у меня дедлайн послезавтра) Хотя посплю всего 2 часа, но все равно похоже придется временно оставить вопрос с этой проблемой и заняться другими моментами драйвера собственно которые меня просили сделать. Ну или применить InterlockedExchange (хочу применить в рабочем потоке призамене указателя, а в каллбаках просто ничего не менять — там же нет ни очистки, ни выделения памяти. Какие проблемы?)
А спинлоки не нравятся тем, что в 24 мксек можно не уложиться из-за тормозов процессора тех же — и будет БСОД.