Mehrere Prozesse in einer "Anwendung"

[sh17]

Nur mal um eine Idee weiter zu verfolgen.

Bei Google Chrome ist es ja z.B. so, dass für jeden Tab ein eigener Prozess gestartet wird. Stürzt die Seite ab, ist nur der eine Tab betroffen und nicht gleich der gesamte Browser.

Könnte man sowas auch mit Delphi-Anwendungen umsetzen? Wo muss ich ansetzen, um so ein Konzept abzubilden - Hauptanwendung (-Prozess) mit Tabs in je einem eigenen Prozess.

[Bernhard Geyer]

Klar kann man sowas machen. Aber lohnt hier der Aufwand?
Von den Browserherstellern wurde das Primär gemacht da Flash und Co. bekannt für Instalbilitäten und Sicherheitslücken sind.

Wenn du sowas bei dir nicht hast lohnt sich das nicht. So ein Umbau wird gefühlt erstmal mehrere Mannmonate Aufwand bedeuten, ohne das der Anwender einen Nutzen davon hat.
Im Gegenteil: Initial wird deine Anwendung erstmal Instabiler laufen bis du den Umbau abgeschlossen hast und alle Bugs die durch den Umbau reingekommen sind beseitigt hast.

[sh17]

Momentan sind alle Module von uns bereits eigene Prozesse. Vielleicht wäre der Aufwand vertretbar gewesen, die Prozesse zu "fangen" und in einer Überanwendung anzuzeigen.

[himitsu]

Du kannst per AcriveX entweder die COM-Objecte innerhalb deiner Anwendung laufen (In-Process) lassen
oder sie in einer externen Anwendung (Out-of-Process) laufen lassen.
https://msdn.microsoft.com/en-us/lib...(v=vs.60).aspx

* COM-Objekt in einer DLL
** DLL im eigenen Programm/Process geladen (In-Process)
** DLL in einem externen Programm geladen (Out-of-Process)
*** hier sind dir vielleich schon Processe wie die DLLHost.exe aufgefallen
* COM-Objekt in einer eigenen EXE (Out-of-Process)

Für dich wären also die Varianten mit Out-of-Process von Interesse.



Man kann auch in der VCL die Processe komplett unabhängig lassen, mit dem anderen Prozess via IPC quasseln (ihn steuern)
und dann dessen Fenster (am Besten ohne Rahmen/Titelleiste) bei sich in ein Panel/PageControl einbinden SetParent.



Der Aufwand lohnt sich nur, wenn man vorallem den Arbeitsspeicher trennen will
und sich davor schützen will, wenn sich Fehler nicht per Try-Except mehr abfangen lassen, weil z.B. "alles" kaputt ist. (Stack und fremder Speicher zerschossen > Bufferoverflow)
Oder bei zu wenig Speicher in 32-Bit-Anwendungen, wenn man den Speicher nicht besser verwalten

[sh17]

Zitat von himitsu:

und dann dessen Fenster (am Besten ohne Rahmen/Titelleiste) bei sich in ein Panel/PageControl einbinden SetParent.

das wäre ja was

[Sherlock]

Zitat von sh17:

Zitat von himitsu:

und dann dessen Fenster (am Besten ohne Rahmen/Titelleiste) bei sich in ein Panel/PageControl einbinden SetParent.

das wäre ja was

Eigentlich ist das etwas zum schnell wieder vergessen - wenn denn das Parenten einer Exe gemeint ist. Da läuft einiges nicht mehr Erwartungskonform. Vergleiche dazu: http://www.delphipraxis.net/1297401-post3.html

Sherlock

[Bernhard Geyer]

Zitat von himitsu:

Für dich wären also die Varianten mit Out-of-Process von Interesse.

Und wenn der Externe Prozess abschmiert/Probleme hat das darfst du dich auch noch mit Windows-COM herumägern.
Hatten wir auch schon das ein Komponente die wir intergriert hatten meinte die eigentliche Arbeit in einem zweiten Prozess laufen zu lassen.
Hat glaube ich fast ein Jahr gedauert (und viele graue Haare) bis der Hersteller die Stabilität halbwegs wieder im Griff hatte.

[Der schöne Günther]

An genau dem gleichen Punkt war ich auch, vor etwa zwei Jahren: "Wäre es nicht total cool, diese Anwendung auf eine Multi-Prozess-Architektur umzubauen?".

Als Beispiel hatte ich auch die Browser Chrome und Internet Explorer gefunden, Firefox hatte das dann später auch. Genau die Stabilität ist von den entsprechenden Entwicklern auch immer als Kriterium angeführt worden weshalb man sich dafür entschieden hat.

Um den Aufwand zu rechtfertigen führte ich noch weitere Vorteile an:
- Steuerung von Lastverteilung mittels Windows-Jobs möglich: Einzelnen Programmteilen können so gezielt Ressourcen zugewiesen werden, wichtige Bestandteile können bevorzugt werden.
- Einzelne Bestandteile könnten auf entfernte Rechner und Nicht-Windows-Systeme ausgelagert werden



Im Endeffekt hatte ich also genau das vor was du mit "Hauptanwendung (-Prozess) mit Tabs in je einem eigenen Prozess." umschreibst.

Um es kurz zu machen: Es war eine absolute Fehlentscheidung. Es hat Zeit gefressen. Es wurde viel gelernt. Heute ist die entsprechende Software immer noch ein monolithisches Projekt und läuft besser und stabiler als jemals zuvor.


Zum einen war der, schon angesprochene, gewaltige Aufwand einzelne Teile zu isolieren und allen die gemeinsame IPC/RPC-Schnittstelle einzupflanzen. Profis hätten da sicher mit (D)COM irgendetwas gedreht. Bei uns kannte sich damit aber niemand gut genug aus und gerade bei "DCOM-Problemen" wurden mir mit leerem Blick und zitternden Händen wahre Schauergeschichten erzählt.

Angenommen man hat diese Hürde nun gemeistert und sein Programm in einzelne Teile zerlegt die nun untereinander kommunizieren. Lief es schneller? Keineswegs. Lief es stabiler? Nein, die Fehlersuche/Debugging wurde dafür aber um eine Zehnerpotenz komplizierter.

Das an sich hätte man noch vertragen können. Der Punkt an dem mir klar wurde dass ich einfach nicht auf Schmerzen stehe ist als die "Minor changes" des Alltags kamen. Kleine Querverknüpfungen, Kunden Sonder-Wünsche. Für jeden kleinen Mist musste eine Schnittstelle geschaffen werden. Für einen kleinen Sonderfall mussten auf einmal Programmteile miteinander sprechen die das Konzept eigentlich penibel sauber getrennt hatte. Wozu hatten wir den Mist eigentlich aufgeteilt?

Grade Delphi ist eine Tool mit welchem man, wenn es schnell gehen muss, auch fünf mal grade sein lassen kann. Für den einen Kunden-Sonderwunsch den er zwei mal im Jahr braucht kann man es auch mal dreckig werden lassen und eine Abhängigkeit schaffen die in einer perfekten Welt nicht da ist. In einer so penibel sauber aufgeteilten Multi-Prozess-Welt in welcher der eine Prozess A jetzt plötzlich Daten aus einem anderen Prozess B haben muss, dieser aber bislang nur mit dem Hauptprogramm Prozess C spricht und diese Daten noch nicht einmal rausgibt ist so etwas ein absoluter Albtraum. In einem monolithischen Programm ist das, je nachdem wie man grade drauf ist, schnell erledigt.


Lange Rede, kurzer Sinn:
Ich stimme Bernhard Geyer voll zu und rate dir es nicht zu tun. Es hört sich in der Theorie toll an. Für die Entwicklung der Browser war das auch die richtige Entscheidung. Die Zuständigkeiten sind hier fest geregelt und jeder Tab tut im Endeffekt das gleiche. Aber auf die wohl meisten Software-Produkte tut man sich mit so etwas keinen Gefallen.

PS: Ja, du kannst z.B. über SetParent(..) Fenster aus anderen Anwendungen einbetten. Der alte Windows-Bildschirmschoner-Dialog ist ein Beispiel dafür.
Aber schau mal welche Erfahrungen man damit auch machen kann:
- http://stackoverflow.com/q/16817112 (Meine Erfahrung)
- https://blogs.msdn.microsoft.com/old...412-00/?p=4683

[Mavarik]

Zitat von sh17:

Könnte man sowas auch mit Delphi-Anwendungen umsetzen? Wo muss ich ansetzen, um so ein Konzept abzubilden - Hauptanwendung (-Prozess) mit Tabs in je einem eigenen Prozess.

Wie himitsu schon gesagt hat... Ne DLL - jede DLL hat ihren eigenen VCL-Thread also eigentlich "einfach" nur die ganze Anwendung in eine DLL packen und ein Hauptprogramm, dass die entsprechenden DLL lädt...

So konsequent habe ich es jedoch noch nicht versucht...

[a.def]

Wie sähe denn bei so einer Umsetzung die Kommunikation zwischen den beiden Programmen aus?
Ganz normale Interprozesskommunikation?