Die Erstellung eines Threads in der DllMain?

Es scheint, dass wenn ein thread erstellt wird von innerhalb von DllMain auf DLL_PROCESS_ATTACH es wird nicht beginnen, bis alle dll ' s geladen wurden. Da ich sicher, dass der thread läuft, bevor ich weiter, bekomme ich eine Sackgasse. Gibt es eine Möglichkeit zu zwingen, den thread zu starten?

InformationsquelleAutor sold | 2009-11-06
  1. 10

    Sollten Sie das nicht tun, werden alle API-Aufrufe, vor allem für Dinge wie das erstellen von threads oder windows, aus DLLMain aufgerufen. Raymond Chen hat darüber geschrieben, das viele Male; hier ist ein das ist besonders relevant.

    • CreateThread ist eines der wenigen Dinge, die Sie tun können, innerhalb von DllMain, weil es ein Aufruf zu kernel32 die ist garantiert schon geladen.
    • Voigt aber extrem vorsichtig sein, da es einfach zu get dead-lock, wenn der aktuelle DllMain aufrufen, wird gebeten, zu warten, für die Rückkehr aus dem neuen thread.
    • Aufruf der wait-Funktionen in DllMain ist sehr schlecht, egal, welche Art von Objekt Sie gewartet haben. In der Regel jeden thread, der die Ausführung von code aus einer DLL haben muss, um einen Verweis für die Zählung auf, dass die DLL, die weniger dem code zugeordnet, unter es. Das verhindert, dass das Problem immer Auftritt, da DllMain dann nicht aufgerufen werden (für Prozess trennen), solange der thread aktiv ist.
    • Obwohl CreateThread sicher sein kann, genannt von DllMain (vorausgesetzt, Sie sind ok mit ihm gekündigt wird und nicht durch Aufruf einer Funktion warten), es ist immer noch eine schlechte Idee, für genau den genannten Gründen in Raymond ' s blog-post: wenn die DLL wird kurz geladen und entladen wird durch eine andere abhängige DLL, die Sie nicht wollen werden, wodurch unnötige Ressourcen (wie Fäden) in diesem Szenario.
    • Ich glaube Hat einen thread erstellt von DllMain deadlock oder nicht? ist noch relevant. Bottom line: Aufruf CreateThread aus DllMain ist sicher (wenn auch nicht empfohlen).
    InformationsquelleAutor Ken White
  2. 5

    Was macht Ihr thread zu tun?

    Werden, wenn Sie versuchen, sich zu bewegen-Zeug auf einen zweiten thread zu vermeiden Sie Einschränkungen auf, was Sie tun können, innerhalb von DllMain, Pech gehabt. Das sind keine Beschränkungen, was DllMain tun können, sind Sie Einschränkungen auf, was kann getan werden, während DllMain ausgeführt wird (und der hält die loader-lock). Wenn dein thread muss, um den loader zu sperren, wird es warten, bis der erste thread beendet ist, es zu verwenden. Wenn dein thread nicht brauchen, die Sperre des Ladeprogramms ich nicht sehen, warum es konnte nicht sofort weitermachen... aber es gibt keine solche Sache wie ein thread, der braucht nicht den loader zu sperren. Windows schicken muss, DLL_THREAD_ATTACH-Nachrichten an alle DLLs, bevor der thread kann mit dem laufen beginnen, was bedeutet, es fordert auch Ihre eigenen DllMain-und Windows-schützt vor re-entrancy.

    Es gibt keinen Weg, um dieses. Der thread kann nicht beginnen, bis nach DLL_THREAD_ATTACH Verarbeitung, und das kann nicht passieren, während dein Erster thread ist innerhalb von DllMain. Die einzige Möglichkeit um ihn herum ist, um einen neuen Prozess starten (hat einen unabhängigen Bootloader sperren und nicht sperren warten auf Euch).

    • Ich habe versucht, eine einfache übung mit CreateThread() für eine sehr einfache Arbeiter Funktion in einem DLLMain() während der Verarbeitung eines DLL_PROCESS_ATTACH Nachrichten. Die thread-Funktion verwendet Sleep() für 1000 Millisekunden. Alles hat gut funktioniert. Ich konnte sehen, wie die DLL_THREAD_ATTACH Nachrichten und DLL_THREAD_DETACH Nachrichten sowohl aus dem ursprünglichen thread zu tun die DLL_PROCESS_ATTACH und den thread erstellt, während des befestigen der Verarbeitung. Aber dieser Arbeitsthread Tat nichts anderes als die Sleep(). Kernel32.dll Anrufe sollen in Ordnung sein. Getestet mit VS 2005-Windows-7.
    • Seltsam genug, dies ist wirklich die einzige Antwort, die befasst sich mit der Frage, die gestellt wurde. Ich weiß nicht, warum die OP entschieden zu akzeptieren, eine Antwort ist das nicht.
    InformationsquelleAutor Ben Voigt
  3. 4

    Nicht. Sie sollten nicht nennen CreateThread (oder jede Variation) von DllMain aufgerufen. Sie versuchen, zu synchronisieren, führt in eine Sackgasse. Was genau wollen Sie tun?

    Best Practices für das Erstellen von DLLs

    • Nichts falsch mit dem Aufruf von CreateThread, aber es gibt keinen Weg um die Tatsache, dass der thread suspendiert werden, bis DllMain-Verarbeitung abgeschlossen ist, in den übergeordneten thread.
    InformationsquelleAutor lyricat
  4. 0

    Sind Sie für Probleme Fragen wenn Sie dies tun. Sollte man nicht machen, alle Anrufe (direkt oder indirekt) Funktionen, die außerhalb der dll ' s (einschließlich der C-Bibliothek ruft, etc.).

    Wenn Sie können nicht ändern die DLL, die Sie haben (z.B. Sie haben keine source-code), Sie könnte in der Lage sein, um Weg mit diesem, wenn die DLL dynamisch geladen, nachdem der rest von Ihr abhängigen DLL ' s werden initialisiert. Ich würde nicht empfehlen diese Methode, wenn Sie es vermeiden können, weil das herausfinden der Abhängigkeiten Kette ist nicht immer trivial ist (z.B. wenn Ihre dll bewirkt, dass eine abhängige dll zu laden, in einem Dritten die dynamisch über COM oder auf andere Weise).

    • Der erste Absatz hier ist eine Verallgemeinerung. Es ist völlig in Ordnung, um Aufrufe in DLLs, die Sie wissen, für eine Tatsache, die bereits einmal geladen wurden, bevor Ihr. Im Allgemeinen und in den meisten Fällen bedeutet dies, KERNEL32.DLL nur, die kann klingen wie eine lähmende Einschränkung, aber Sie können es verwenden, um bootstrap Ihren Weg aus dieser situation.
    • blogs.msdn.com/oldnewthing/archive/2007/09/04/4731478.aspx
    • Dank Der Integer-Dichter. Das beantwortet genau die Frage, die ich hierher gekommen, um zu lösen.
    • Sowohl kernel32.dll und ntdll.dll garantiert sind, zugeordnet werden, ein Prozess, Adressraum vor seiner bootstrapping-code ausgeführt wird.
    InformationsquelleAutor Peter Tate
Schreibe einen Kommentar