Plaats DLL-blokkerende UI-thread

In mijn toepassing zijn bepaalde dll's alleen vereist voor specifieke bewerkingen die niet zullen voorkomen voor 99,9% van de gebruiksbewerking. Dus om te besparen op laadtijd en geheugen worden deze dynamisch geladen geladen zoals vereist met behulp van LoadLibrary .

Om de gebruiker op de hoogte te houden en het programma reageert, worden de bibliotheken geladen op een sperate-thread en vervolgens wordt de UI-thread gemeld wanneer ze beschikbaar zijn en kan het proces worden voortgezet.

In mijn experimenten, terwijl LoadLibrary actief is, wordt de UI-thread vergrendeld en wordt de gebeurteniswachtrij toch niet verwerkt, waardoor die toepassing wordt vergrendeld en het scherm niet langer opnieuw wordt getekend.

MSDN op LoadLibrary vermeldt dit gedrag niet, is het mogelijk om een ​​dll in een thread te laden terwijl de wachtrij voor de gebeurtenis nog steeds wordt verwerkt?

1
Dit is onnodige zelf-straf. Gebruik de linker/DELAYLOAD optie.
toegevoegd de auteur Hans Passant, de bron
Wat doet de UI-thread als hij stopt met het pompen van berichten? (Dat wil zeggen, als u de foutopsporing koppelt terwijl het niet pompt, wat roept dat dan?)
toegevoegd de auteur James McNellis, de bron
Als de dllMain in de geladen dll lang duurt, wordt de loaderLock even lang aangehouden. U kunt zich dan gemakkelijk voorstellen dat de GIU-thread op de loaderLock wordt geblokkeerd. Dit zou ook gemakkelijk te gebruiken moeten zijn met de debugger zoals James suggereerde.
toegevoegd de auteur Kjell Gunnar, de bron
Goed idee vergeten om dat te doen, zal ik controleren
toegevoegd de auteur JProgrammer, de bron

1 antwoord

Er is geen probleem bij het laden van dll's asynchroon. Het had te maken met de Visual Studio Debugger die symbolen opzocht voor de nieuw geladen dll's van de symbol servers.

When symbol servers are disabled or the application run without a debugger there is no locking present the execution of LoadLibrary

Debugging Symbols

1
toegevoegd