Huhu

Ich arbeite momentan grad an einer eigenen Scripting IDE, die Zugriff auf die VCL aus verschiedenen Threads heraus erlauben soll. Dabei möchte ich aber möglichst nicht die Standardlösung via TThread.Synchronize verwenden, da die Scripts sonst nicht sauber von einander getrennt sind (wenn z.B. ein Script den Mainthread blockiert, blockieren auch alle anderen Scripts).

Wie das gehen soll? Genau so: Jedes Script hat einen eigenen Thread und eine eigene Message Pump. Jedes Script erstellt seine eigenen VCL Objekte dynamisch und greift auch nur auf die eigenen Objekte zu. Man hat also eigentlich die totale Trennung und jedes VCL Objekt wird immer nur von einem Thread angesprochen und merkt also gar nix davon, dass es da noch andere Threads gibt.

Soviel zur Theorie. In der Praxis gibt es dann halt doch einige Problemchen, wo völlig verschiede Objekte trotzdem auf gemeinsame Ressourcen zurückgreifen, z.B. in TCanvas, wo man die Lock Methode braucht, weil die dem Objekt zugrunde liegenden Funktionen (Win32 GDI Zeugs) dann anscheinend doch wieder global innerhalb des Prozesses sind. Oder auch andere Funktionen wie ChDir() etc, die natürlich auf alle Threads einen Einfluss haben und daher mittels Mutex synchronisiert werden müssen. Diese offensichtlichen Kandidaten sind aber nicht das Problem. Schwierig wird es, wenn in den Gedärmen der VCL irgendwo gemeinsame Daten geschrieben werden, die man so von aussen nicht sieht.

Hat jemand von euch mit sowas schon Erfahrungen gesammelt? Gibt es in der VCL versteckte Shared Resources?

Moin und im Forum!

Ich habe noch nie eine Anwendung gesehen, die Zugriffe auf VCL-Komponenten aus einem anderen, als dem Hauptthread heraus, sauber hinbekommen hätte.

Deshalb: vergiss es - jedenfalls mit der VCL... Trotzdem viel Erfolg.

cu
Narses

Hallo und auch von mir,

zu viele Threads sind eh ziemlich oft eine eher schlechte Idee. Ein paar sind sicherlich oft sinnvoll, aber mehr als ein Dutzend imho selten. Und wenn die Synchronisation mit dem VCL-Thread der Flaschenhals wird, sollte man evtl. das Konzept überdenken.

Zum Beispiel: ist wirklich jeder Synch-Aufruf notwendig, oder können einige verworfen werden, wenn die VCL gerade beschäftigt ist?

Huhu, danke für das freundliche Willkommen und die Antworten Werd ich wohl selber mal in die Eingeweide abtauchen und nachgucken müssen. Geht halt vor allem um die globalen Variablen. Prinzipiell sollte es nämlich gehen, da bin ich mir sicher.

Falls es wen interessiert: Mein Projekt erlaubt es, beliebige Delphi Objekte (auch VCL) auf sehr einfache Weise in eine DLL zu packen und von aussen her von jeder Sprache aus zugreifbar zu machen. Also sowas wie COM/ActiveX, nur eben mittels einfachem DLL Interface.

Als Scriptsprache verwende ich Lua, da man die Zugriffe auf die DLL sehr schön mit Lua eigenen Objekten nachbilden kann, z.B sowas:



Dabei hängt die DLL aber in keinster Weise von Lua oder sonstwas ab.

Liebe Grüsse
Roffel

Moin!

Roffel hat folgendes geschrieben :

Werd ich wohl selber mal in die Eingeweide abtauchen und nachgucken müssen. Geht halt vor allem um die globalen Variablen. Prinzipiell sollte es nämlich gehen, da bin ich mir sicher.

Prinzipiell ist Windows threadsave, ja. Aber eben die VCL nicht. Und wo wir gerade dabei sind: welche Version der VCL soll es denn sein? Oder wolltest du dich auf eine bestimmte Delphi-Version festlegen (und damit alle andern ausschließen)?

Wie dem auch sei, ich bin gespannt! wird wohl ein "eigenes Betriebssystem"-Thread werden, schätze ich *g*

cu
Narses

Die einzelnen VCL Objekte müssen ja nicht threadsave sein. Ich greif auf jedes Objekt nur von jeweils einem Thread aus zu. Nur sind's halt mehrere Threads und mehrere Objekte.

Ich hab zwischenzeitig herausgefunden, dass die Fensterobjekte trotz totaler Isolierung via globales Screen Objekt voneinander wissen (tragen sich unter Benutzung eines Mutex beim Init/Destroy in ne Liste ein/aus) und sich gegenseitig Nachrichten zuschicken, für Fensterfokus und Hints etc. Das Ganze läuft soweit threadsafe ab, bis auf ne kleine Winzigkeit: Wenn z.B. ein Thread mit einem Fenster hängt (in ner Sleep Loop wenn man ein Script pausiert) und man dann dieses eingefrorene Fenster klickt, dann sendet das andere Fenster ne Nachricht via SendMessage und wartet im Unterschied zu PostMessage eben auf ne Antwort, die wegen der nicht abgearbeiteten Message Loop ausbleibt. ^^ Also friert unter Umständen gleich alles ein bis man das eine Fenster wieder laufen lässt und alles erholt sich. Kann man prima umgehen indem man in der Sleep Loop trotzdem die Nachrichten im Bereich $B000-$BFFF checkt und verarbeitet.

Wie dem auch sei... sehr speziell das Ganze. Aber nun ja gelöst und geht soweit prima. *freu*