Multithreaded/MultiprocessTabbed-UI - wie realisieren?

[Codehunter]

Moin, mitten im verlängerten Wochenende

Ich spiele gedanklich die verschiedenen Möglichkeiten durch, wie man ein Tabbed-UI realisieren könnte, das ähnlich modernen Webbrowsern jeden Tab in einem eigenen Thread bzw. besser noch eigenen Prozess laufen lässt. Es gibt also noch keine konkreten Quellcodes sondern nur Gedankenspiele.

Multiprocessed hätte für mich im Augenblick die Nase vorn. Die zuerst gestartete Instanz der Anwendung wäre automatisch als Mutteranwendung gesetzt. Evt. in der Art, dass die eigentliche Containeranwendung/Mutteranwendung eine separate Exe ist, die vom zuerst gestarteten Tabbed Process "nachgestartet" wird falls nicht vorgefunden. Nachfolgend gestartete Instanzen würden als erstes nach einer bereits laufenden Instanz suchen und falls vorhanden, dieser eine Message schicken wie "Hier bin ich, mach mir mal einen kuscheligen Tab auf, wo ich mich rein setzen kann. Hier hast schon mal mein Window-Handle..." Die Mutteranwendung würde dann per FindWindow/SetParent den Nachzügler einfangen und einsortieren. Das gesamte grafische Management würde dann das Betriebssystem automatisch übernehmen, ebenso das Speichermanagement und die Abschottung der Speicherbereiche. Sollte so ein Tabbed Process dann doch mal crashen, könnte ich mittels Tools wie Madexcept innerhalb des Todeskandidaten noch reagieren und der Mutteranwendung eine entsprechende Message schicken.

Multithreaded hätte IMHO einige Nachteile. Einmal müsste ich mich um die ganze UI-Synchronisierung selbst kümmern: Den Thread im aktiven Tab mit der Pinselei beauftragen und die Tabs im Hintergrund von dieser Aufgabe befreien. Zweitens bin ich nicht sicher ob mit einem multithreaded Tabbed-UI eine höhere Absturzsicherheit verbunden wäre. Denn IMHO nimmt ein gecrashter Thread seine Mutteranwendung ja mit in den Tod.

Soweit meine Überlegungen. Was haltet ihr davon?

Grüße
Cody

[Der schöne Günther]

An genau dieser Stelle war ich vor ein paar Jahren auch. Es war eine der besten Entscheidungen das nicht zu tun.

Was genau versprichst du dir davon? Ich dachte auch ich erhalte eine höhere Absturzsicherheit. Und wenn Webbrowser das mit ihren Tabs so machen, dann muss das ja toll sein. Du sprichst nur von UI. Hast du wirklich x mal das gleiche? Dann würde ich vielleicht noch einmal drüber nachdenken. Aber nicht wenn es nur um die Anzeige geht.

Zitat:

Sollte so ein Tabbed Process dann doch mal crashen, könnte ich mittels Tools wie Madexcept innerhalb des Todeskandidaten noch reagieren und der Mutteranwendung eine entsprechende Message schicken.

Wenn ein mittels SetParent gehostetes Fenster hängt dann bringt das auch deine Mutter-Anwendung zum Aufhängen.

Siehe eine Frage von mir als ich grade mit Delphi anfing
https://stackoverflow.com/q/16817112/2298252

[Codehunter]

Zitat von Der schöne Günther:

Was genau versprichst du dir davon?

Ich habe schon verschiedene Tabbed-Anwendungen geschrieben, alle Single-Threaded. Solange praktisch alle Aufgaben der Anwendung anwendergetriggert sind, ist das überhaupt kein Problem.

Aber schon wenn man nur einen simplen Timer verwendet, um regelmäßig z.B. einen Dateiimport zu machen, spürt man anwenderseitig Verzögerungen. Gerade dieser Import geht gerne mal baden, weil die externen Zulieferer dieser Dateien (meist Anwendungen von Drittanbietern) erfahrungsgemäß immer mal wieder Nonsens abliefern. Das schickt meine Anwendung trotz großzügigem Gebrauchs von try-except immer mal wieder ins Nirvana.

Deshab habe ich den Dateiimport auch noch nicht in Threads ausgelagert. Denn dem Aufwand des Programmumbaus stand die Frage gegenüber, ob ich so nur das Problem der Reaktionslatenz beheben kann, weil soweit ich weiß eben gecrashte Threads die ganze Anwendung mitnehmen (lasse mich da gerne eines besseren belehren)

Anders als bei Webbrowsern wären die einzelnen Tabs nicht funktionsidentisch, sondern hätten spezialisierte Aufgaben (z.B. Lager, Artikelstamm, Stammdatenbearbeitung etc.). Diese grundlegende Programmstruktur ist so schon vorhanden, müsste also nicht grundlegend umgebaut werden, wollte ich das ganze in einer Art Multiprocess-Design laufen lassen.

Aber weil Zeit und Geld eine enge Wechselbeziehung haben, wurschtel ich nicht einfach drauflos sondern hör mir gerne mal an was andere für Erfahrungen gemacht haben.

[Schokohase]

Dann beschreibe doch mal mit fachlichem Vokabular, was man sich unter so einem "Crash" vorzustellen hat.

Wird da der Prozess-Speicher überschrieben und dadurch wird der laufende Prozess instabil, oder sprechen wir von einer simplen (und daher harmlosen) Exception?

[Der schöne Günther]

Das hört sich für mich allerdings auch eher so an als sollte man eher bei dem Teil der die Daten importiert und verarbeitet einsetzen. Sammele doch erst einmal solche Nonsens-Daten und stelle nach wie sich dein Programm verhält. (Noch besser: Schreibe Unit-Tests )

Du musst schon ziemlich wilde Dinge anstellen wenn das deine ganze Anwendung beendet. Was genau tritt auf? Eine Exception bis ganz nach oben sodass Windows dein Programm beendet? Wenn ja, was sagt der Windows Event Viewer dazu? Was dein Exception-Logging?

Zitat von Codehunter:

Anders als bei Webbrowsern wären die einzelnen Tabs nicht funktionsidentisch, sondern hätten spezialisierte Aufgaben (z.B. Lager, Artikelstamm, Stammdatenbearbeitung etc.).

Über was sollte deine IPC laufen? Vielleicht habe ich da zu wenig Erfahrung, aber ich sehe allein im Datenaustausch schon ziemlichen Aufwand und weitere Stellen wo es Probleme geben kann.

[Codehunter]

Zitat von Schokohase:

Dann beschreibe doch mal mit fachlichem Vokabular, was man sich unter so einem "Crash" vorzustellen hat.

Wird da der Prozess-Speicher überschrieben und dadurch wird der laufende Prozess instabil, oder sprechen wir von einer simplen (und daher harmlosen) Exception?

Eines der für mich bisher ungelösten Probleme ist, dass ich für die importierten Daten (uneleganterweise Binär und nicht strukturiert) umfangreiche Plausi-Checks einbauen musste. Das habe ich inzwischen auch soweit im Griff, dass das Ganze defakto whitelisted arbeitet. Allerdings gibt es einige undokumentierte Chunks, die ich nur anhand eines Byte-Markers als solche erkennen kann. Deren Verarbeitung mache ich nicht selbst sondern übergebe den gesamten Speicherblock als Shared-Memory an eine zugelieferte DLL. Leider ist die Zusammensetzung der undokumentierten Chunks genauso unzuverlässig wie die der dokumentierten Teile. Meist läuft ein solcher Crash innerhalb der DLL dann auch einen Pufferüberlauf hinaus, seltener Zugriffsverletzungen.

Das kann man dem Zulieferer vorwerfen wie man will, die juckt das nicht weil "Gelassenheit durch Größe". Der Endanwender sieht nur die Zuverlässigkeit des Gesamtkonstrukts, auf dem unser Logo pappt.

[TiGü]

Wäre es nicht sinnvoll, dann den Import per abgesetzten Prozess anzustoßen? Dann kann der kleine Import-Prozess mit der DLL abstürzen wie er will und du kannst ihn von außen steuern.

[Codehunter]

Hängt euch nicht zu sehr an der Importproblematik auf. Das war letztlich nur der Stein des Anstoßes. Das Thema als solches, also grundlegend, hat mich interessiert. Also wie man, so man das wollte, eine Multi-Prozess-Anwendung mit Tabbed-UI sinnvollerweise konstruieren sollte und ob aus euren Erfahrungen heraus der Aufwand lohnt.

[TiGü]

Mach es nicht! Der Aufwand ist nicht immens hoch. Hatten wir nicht neulich dazu einen Thread?

[himitsu]

Vor allem sind die MultiProcess-Umsetzungen nicht vorrangig wegen der Verbesserung durch Multithread entstanden, sondern wegen der Sicherheit von "unsicheren"/schrottigen Programmen/Codes.

Fehler in einem "Tab" sorgen nicht für den Absturz des gesamten Programms.
Und auch Fehler in punkto Sicherheit werden ausgeglichen, da getrennte Speicherbereiche und kein Zugriff auf Speicher der anderen Tabs (z.B. Passwörter/Verschlüsselung über Webseitengrenzen auslesen)


Multithread alleine bringt auch selten Vorteile, wenn/da die GUI-Frameworks oftmals nicht threadsave sind. Das umgeht man durch Multiprozess, da jeder seine eigenen globalen Objekte besitzt, falls man das nicht untereinander verknubblt.

Rechenintensive Dinge sollte man eh nicht im GUI-Thread machen, womit es selten Vorteile bringt das Wenige auch noch auf mehrere Threads/Prozesse zu verteilen.
Mit nur Multithread wird es sogar schlimmer, wenn man dann auch noch ständig synchronisieren muß.


OK, eines der Speicherprobleme bei 32 Bit wird auch behoben, da jeder Prozess seine eigenen 2/4 GB virtuellen Speicher besitzt.