Multithreaded/MultiprocessTabbed-UI - wie realisieren?

[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?

[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.

[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.