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

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

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.