CarstenB - Mi 19.03.14 18:23
Titel: DLLs in Hintergrund-Thread laden

---

Hallo,

ich habe folgendes Problem.

Mit wachsender Komplexität einer Applikation müssen ein Haufen DLLs geladen werden, was sich zur Laufzeit durch unschöne Verzögerungen bemerkbar macht.
Ich habe nun verschiedene Ansätze probiert, u.A. die DLLs in einem Hintergrundthread (LoadLibrary) vorzubereiten.

Das Problem ist jetzt, dass damit die Message-Queue der Haupt-Applikation nicht mehr greift. Eine zusätzliche Message-Queue möchte ich eigentlich vermeiden.

Gibt's einen Ausweg? :)

MfG.


Moderiert von Narses: Topic aus Sonstiges (Delphi) verschoben am Do 20.03.2014 um 11:43

Delete - Mi 19.03.14 18:31

---

Crosspost [http://www.delphipraxis.net/179609-dlls-hintergrund-thread-laden.html]

jaenicke - Mi 19.03.14 23:49

---

CarstenB hat folgendes geschrieben :

Das Problem ist jetzt, dass damit die Message-Queue der Haupt-Applikation nicht mehr greift.

Da ist dann erst einmal die Frage was dabei gemacht wird, dass das ein Problem ist?
Wenn du mit visuellen Komponenten etwas machst, geht das ja ohnehin nur im Hauptthread.

Delete - Do 20.03.14 04:25

---

CarstenB hat folgendes geschrieben :

Mit wachsender Komplexität einer Applikation müssen ein Haufen DLLs geladen werden, was sich zur Laufzeit durch unschöne Verzögerungen bemerkbar macht.

Zwei Möglichkeiten:

1. DLLs nicht alle auf einmal, sondern dynamisch laden, wenn sie benötigt werden. Hat den Nachteil, daß das Aufrufen einer entsprechenden Funktionalität länger dauert.

2. Splash-Screen anlegen und alle DLLs auf einmal beim Programmstart laden, ggf. mit Anzeige des Ladevorgangs, damit der Anwender beruhigt ist.

Das Laden in einem Thread birgt die Gefahr, daß der Anwender Funktionalitäten der Applikation abrufen möchte, die eine noch nicht geladene DLL benötigen. Daher würde ich dem Anwender nicht gestatten, auf die Funktionalität des Programms zuzugreifen, bevor das Programm vollständig zur Verfügung steht.

jaenicke - Do 20.03.14 07:00

---

Perlsau hat folgendes geschrieben :

Das Laden in einem Thread birgt die Gefahr, daß der Anwender Funktionalitäten der Applikation abrufen möchte, die eine noch nicht geladene DLL benötigen. Daher würde ich dem Anwender nicht gestatten, auf die Funktionalität des Programms zuzugreifen, bevor das Programm vollständig zur Verfügung steht.

Oder man macht es richtig und erstellt einen Pool, der entweder den schon geladenen DLL-Wrapper liefert, wenn dieser benötigt wird, oder das Laden priorisiert, wenn die DLL noch nicht durch den Thread geladen wurde.

So habe ich das sowohl mit DLLs als auch mit Datenbanken schon umgesetzt, auch nachträglich in einem schon bestehenden Projekt, das geht eigentlich relativ einfach, ist aber natürlich mit einigem Aufwand verbunden.

CarstenB - Do 20.03.14 11:50

---

In den DLLs laufen selbst auch wieder Threads für Kommunikation, Datenaufbereitung, etc. Zur Kommunikation mit dem Hauptprogramm und VCL-Synchronisierung werden neben Callback-Funktionen auch Messages verwendet.

Dynamisches Laden ist der Status Quo, was aber eben an einigen Stellen zu den genannten Verzögerungen führt. Durch das "Vorladen" ist dieser Effekt recht gut in den Griff zu bekommen.
Welche DLLs bereits geladen sind ist in der Komponente bekannt. Diese enthält einen Pool, wie von jaenicke erwähnt - für aufrufende Funktionen gibt es kein Problem.

jaenicke - Do 20.03.14 12:12

---

Das hört sich relativ ähnlich an zu dem was wir bei solchen Fällen machen.

Mit den Messages hatten wir da aber bisher keine Probleme. Das einzige Problem war, dass Synchronize in den DLLs so nicht ging, aber das ließ sich durch Aufrufe von CheckSynchronize über eine exportierte Funktion der DLL, die im Hauptprogramm aus OnIdle heraus aufgerufen wird, beheben.