В продолжение темы про использование NamedPipes.
По рекомендации dumb вместо пайпов стал использовать MMF.
Работа с mmf производится в доп.потоке, данные добавляются асинхронно.
Проблема:
при аттаче dll в процессы, они подвисают на создании этого доп.потока, обслуживающего mmf.
Подвисают на строках в конструкторе:

Ошибка в лог выводится каждый раз одна и та же - 1444, ERROR_INVALID_THREAD_ID. Несмотря на то, что в действительности поток создается и работает нормально (данные от него через mmf приходят исправно).
Очередь сообщений доп.потока так же создается и используется:



тестовый пример - во вложении.

Где я не прав?

Добавлено через 1 минуту и 17 секунд
ай-я, пока редактировал - вложение потерялось :(
вот оно.

Присоединённый файл ( Кол-во скачиваний: 5 )
 mmf_hook.rar 8,34 Kb

на сколько я помню, не рекомендуется делать лишние телодвижения(в т.ч. создавать потоки) в DllMain при загрузке библиотеки...

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

точно, нашел такое...
DllMain callback function, в ремарках.

Если точнее, то


А як жеш быть?
imho, лучше 1 раз потерять во времени при инициализации, чем каждый раз на вызове хука для синхронизации обращения к разделяемому ресурсу...

Это сообщение отредактировал(а) kami - 17.5.2009, 16:23

кстати, а как вообще написана DllMain?

В файл пишется только для отладки, в готовом коде это будет убрано.

Цикл в конструкторе доп.потока могу убрать, но тогда нет уверенности в том, что при обращении к его методам он будет уже проинициализирован.

Сейчас пришла мысль:

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

Добавлено через 3 минуты и 52 секунды

расшифруй плиз...
в общем тут дело такое - создать то поток можно, но нельзя в него "лезть" из dllmain. а инициализировать можно все в Execute потока.
ибо, как написано у Рихтера, все DllMain вызываются линейно.
и у тебя как раз такая ситуация, что поток не будет запущен, пока не отработает DllMain c DLL_THREAD_ATTACH, а она не запустится, пока не отработает DLLMain с DLL_PROCESS_ATTACH

Хук пишет данные в mmf, основная программа "выгребает" их.
Чтобы не было накладок (один недописал, второй уже считал и обнулил mmf) идет синхронизация с помощью мьютексов.
Если добавлять данные в mmf непосредственно из потока, в котором вызыван хук, то неизвестно, сколько времени будет потеряно на WaitFor-ожидание, что для хука недопустимо. Посему было сделано так - данные из хука в доп.поток, работающий с mmf, передаются с помощью PostThreadMessage, что не задерживает выполнение хука. А этот доп.поток пускай ждет сколько угодно - его ожидания не лимитируют.

Это и имел ввиду, говоря "лучше день потерять, зато потом за 5 минут долететь"     


Ух ты...
спасибо, буду знать.

kami, а какой смысл в конструкторе потока слать PostThreadMessage? чтобы убедиться, что создалась очередь сообщений потока?неужели это настолько критично?

В условиях данной задачи (имеется ввиду - полной задачи, а не этого упрощения) - некритично.
Но я не люблю что-то сделав, возвращаться потом к тому же вопросу для доработки. (например, в разрабатываемом классе есть ф-и AddData, GetAllData, но нет GetFirstData).
Вдруг в другой задаче нужно будет отправить критически важные данные сразу после создания MMFThread?

Предпочитаю делать что-либо с претензией на какую-никакую, а универсальность   

кстати... к алгоритму можно придраться... имхо - он не надежен.
ибо Post{Thread}Message не гарантирует доставку сообщения. а ты наверняка передаешь с пом.него данные, которые затем будут очищаться в потоке? а если потоку сказали Terminate, он завершится не обработав возможно ожидающие в очереди сообщения...
в общем мое мнение: сообщения можно здесь использовать только для нотификации, но никак не для передачи важных данных.

Добавлено через 11 секунд
з.ы. конечно же я могу быть не прав

Подробное описание проблем с DllMain (серия на 4 поста).
Далее, из ERROR_INVALID_THREAD_ID - двойку вам за знание TThread. Поток запускается ТОЛЬКО после выхода из конструктора (в AfterConstruction). Хитроумные манипуляции с Resume здесь не к месту. Вставьте этот код на Execute. Даже, если вы оставите подобный подход - нет гарантии, что поток успеет создастся до вызова PostThreadMessage - вам всё равно нужна доп. синхронизация.
И ещё MetalFan прав насчёт возмодности пропуска сообщений. Для синхронизации потоков надо использовать события, крит. секции и др. объекты.

Совершенно верно.
PostMessage(msgAddData, integer(pData), DataSize);

Поток будет терминирован, если:
1. Завершено приложение, в которое внедрен хук.
2. Вызывано UnHookWindowsHookEx для всех установленных из dll хуков.

И в том и в другом случае приходящие после этого данные уже не актуальны.

Протестую!


А AfterConstruction только и делает, что вызывает Resume при необходимости.
Я же вызывал его в явном виде в своем классе после inherited Create(True). Просветите меня, если это ошибочно.

В Execute выполняется код, предназначенный к выполнению в доп.потоке, инициализация данных и ожидание начала работы потока должны происходить не в нем.

Как раз-таки этот цикл гарантирует, что:
1. поток запущен и вошел в Execute.
2. Очередь сообщений инициализирована и работает.

Добавлено через 4 минуты и 52 секунды

Тем самым стопоря работу осн.потока.
Самым простым методом синхронизации будет создание окна в доп.потоке и передача данных в него с помощью SendMessage, что гарантирует поступление данных в поток до выхода из оконной процедуры, т.е. до выхода из SendMessage.

Такая возможность заложена, в примере (вложение первого поста) реализована.

Добавлено через 11 минут и 44 секунды

Уже понял из msdn.
Кошмар!
dll придется пересматривать :(

Это сообщение отредактировал(а) kami - 17.5.2009, 22:14

ну уж извините) и рыбку съесть и....  не получится. либо синхронизация либо возможная порча данных. а синхронизация с пом. SendMessage конечно проста, но имхо не самый быстрый и надежный вариант.

Это сообщение отредактировал(а) MetalFan - 18.5.2009, 12:40

Нет, почему же: MsgWaitForMultipleObjects (см. также TThread.WaitFor). 
Да даже, если просто тупо WaitForSingleObject - там "завис"-то будет в сотые доли секунды. И уж всяко меньше вашего Sleep(100). Что, долго потоку раскручиваться, что-ли?


А о том, что Resume в AfterConstruction вызывается - вы не подумали?
Такие действия надо делать так:



Да, что-то я не так этот код прочитал   
Тогда проверяйте свой код - должен работать. Может, конечно, первая итерация и с ERROR_INVALID_THREAD_ID будет, но вторая - успешно.
Что-то мне кажется, вы с i напутали.

а что в этом плохого, если поток и так запущен?

За исключением того, что мы городим кривой код на ровном месте - ничего ;)

CodeMonkey, 
ну с одной стороны, делать Resume в конструкторе TThread нам ничего не мешает, но с другой - это нарушает идеология самого класса...

Подумал давно, и тогда же посмотрел.

И зачем мне перекрывать еще и этот метод? Не вижу разницы в вызове Resume в AfterConstruction или в конструкторе после inherited.


Вопрос:
а что ждать?
В конструкторе ничего не создается.
В процедуре потока - мьютекс, MMF и окно. Но! Они могут быть не-инициализированы даже после отработки AfterConstruction, ибо кто кроме планировщика потоков Windows может знать, когда управление в первый раз будет отдано в этот новый поток?

Теперь, с учетом 

работает. Правда, одно лишнее телодвижение осталось - создание потока. Вот только без ожидания его инициализации. Потокобезопасные процедуры работы с ним позволяют безболезненно обойти это, за исключением 2-х моментов:
1. поток создан, но данные в execute не инициализированы. В этом случае утечек нет.
2. Поток жестко терминирован. Утечки будут. Малого размера, но будут.

тебя это, похоже, не должно беспокоить...


т.е. необработанное сообщение приведет опять же к небольшой утечке памяти.

Да.
Я не думаю, что утечка в 2*SizeOf(integer) - большая проблема для чужого приложения. Даже случившаяся несколько раз.

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

На сервере подкачка = смерти ;)

/me тяжко вздыхает.
Знаю. Читал. Стараюсь свести к минимуму.
Но синхронизацию при добавлении данных использовать не могу. В данном случае.

В любом случае - огромное спасибо MetalFan и CodeMonkey за помощь.
Без вас наверное, до сих пор зависал бы на конструкторе потока, пытаясь понять отчего же он не работает.

Кстати, это может объяснить и неработоспособность компонентов-оберток над namedPipes, которые и послужили началом разбирательства на предыдущую и эту темы.

kami, я правильно понимаю: избегая "блокировки" на "ожидании" мьютекса, ты создаешь поток, чтобы "быстро" туда постить инфу?
тогда тебе удалось сделать из мухи здоровенного такого африканского слона. 

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

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

сдается, что в данном случае такая категоричность безосновательна.

"Premature optimization is the root of all evil" (с)

Мне тоже кажется, что вы что-то не то делаете, но мне как-то лень копаться   
В общем случае надо бы убрать всё из DllMain, все вещи инициализировать по первому обращению, а глобальные ресурсы хранить в глоб. переменных/threadvar/списке и удалять при выгрузке DLL. Плюс предусмотреть ситуацию переустановки хука без выгрузки DLL.

Нет, этого я  не избегаю.
Работа доп.потока организована в строгом соответствии с Вашими рекомендациями в предыдущей ветке.
А вот добавление данных из другого потока сделано как PostMessage(hwnd, msgAddData, integer(@Data), DataSize);


Именно так.


Спорить не буду, т.к. учусь, в основном - на своих ошибках .

Согласен, чужой код, как и душа - потемки.


Уже думал, попробую и этот вариант.

Ага, для меня сейчас это самое узкое место.

Как-то так:

DLL:


App:


Добавлено через 3 минуты и 8 секунд
Немного непонятно, на что конкретно ставиться хук. В принципе, если хук, скажем, на GetMessage, то вместо DeleteHookData при process detach можно делать broadcast сообщения, по которому отцепляется DeleteHookData. Ну и в DLLProc вызов всё же оставить - на всякий пожарный.

народ, не настаиваю, но может таки на "ты"? - общение все же не официальное.

для чего тогда вообще создается доп.поток в контексте чужого процесса? - из обработчика хука сразу класть в mmf структуру.

эм. я насчет доп.потока ничего не говорил. сейчас, исходя из того, что вижу в коде hlibstaex, еще раз скажу: не нужен доп.поток.

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


Ок, переделать из потока в обычный класс, обслуживающий mmf - небольшая проблема. Попробую.

Вах!

а это как?
Присоединённый файл ( Кол-во скачиваний: 1 ) - это ж я скачивал, чтобы проверить работоспособность ссылки     


Примерно так и думал.
Единственное - до этого времени не держал открытой GlobalData.