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