Создание потока в DllMain?
Кажется, что когда поток создается изнутри DllMain на DLL_PROCESS_ATTACH Он не начнется, пока не будут загружены все dll. Поскольку мне нужно убедиться, что поток работает, прежде чем я продолжу, я получаю тупик. Есть ли способ заставить нить начать?
4 ответов
вы не должны делать никаких вызовов API, особенно для таких вещей, как создание потоков или окон, из DLLMain. Раймонд Чен писал об этом много раз; вот один это особенно актуально.
что нить сделать?
Если вы пытаетесь переместить материал во второй поток, чтобы избежать ограничений на то, что вы можете сделать внутри DllMain, не повезло. Это не ограничения на то, что DllMain может делать, это ограничения на то, что можно сделать во время работы DllMain (и удерживает блокировку загрузчика). Если ваш поток должен взять блокировку загрузчика, он будет ждать, пока первый поток не закончит его использовать. Если ваш поток не нуждался в блокировке загрузчика, я не понимаю, почему он не мог немедленно продолжить... но нет такой вещи, как поток, который не нуждается в блокировке загрузчика. Windows должна отправлять сообщения DLL_THREAD_ATTACH во все библиотеки DLL до запуска потока, что означает, что он также вызывает ваш собственный DllMain, а Windows защищает от повторного входа.
ничего не поделаешь. Поток не может начаться до обработки DLL_THREAD_ATTACH, и это не может произойти, пока ваш первый поток находится внутри DllMain. Единственно возможный способ обойти это запустите новый процесс (который имеет независимую блокировку загрузчика и не будет блокировать ожидание вашего).
нет. Вы не должны вызывать CreateThread (или любое изменение) из DllMain. Попытка синхронизации приведет к взаимоблокировке. Что именно ты пытаешься сделать?
вы напрашиваетесь на неприятности, если сделаете это. Вы не должны делать никаких вызовов (прямо или косвенно) функциям, которые находятся за пределами вашей библиотеки dll (включая вызовы библиотеки C и т. д.).
Если вы не можете изменить DLL у вас есть (например, у вас нет исходного кода), Вы может иметь возможность уйти с этим, если ваша DLL динамически загружается после инициализации остальных зависимых DLL. Я бы не рекомендовал этот подход, если вы можете избежать этого, потому что выяснение цепочка зависимостей не всегда тривиальна (например, если ваша dll заставляет зависимую dll динамически загружать третью через COM или некоторые другие средства).