Multithreaded/MultiprocessTabbed-UI - wie realisieren?

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

[Codehunter]

Zitat von himitsu:

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

Daran hab ich noch gar nicht gedacht! Haste Recht! Wobei ich ja nicht NUR mit der Starter unterwegs bin sondern durchaus auch (ältere) Professional habe, getrennt nach gewerblich und Hobbyprojekt. Insofern baue ich das meiste eh in 64 Bit.

Die Abschottungsproblematik ist auch in meinem Fall die treibende Kraft für die Idee, weil ich viel mit externem Code in Form von DLLs arbeiten muss. Das obige Import-Beispiel ist nur eins von mehreren. Wenn ein "getabbter" Prozess crashen sollte, wäre halt meine Wunschvorstellung gewesen, dass eben auch nur dieser Tab geschlossen würde und nicht die gesamte Anwendung. Das Konzept würde jedenfalls gut zum bisherigen Anwendungsdesign passen, das bereits ein Tabbed-UI ist, nur eben single-threaded.

[p80286]

Mach es nicht!
Ich habe etwas ähnliches gebastelt. Die drei WorkerThreads zu definieren und eine reagierende Oberfläche ist nicht soo das Problem. Aber wenn Dir andere Prozesse hineingrätschen können, mußt Du jede erdenkliche Fehlerkonstellation beachten.
Die einfache Möglichkeit ist natürlich ein Log zu erstellen, das dann hinterher jemand abarbeiten muß. Je nach Datenabhängigkeit ist dann natürlich großes Aufräumen angesagt. Was intelligent Logs etwas erleichtern.
Meiner Meinung nach sind aber beide Wege ähnlich aufwendig.

Gruß
K-H

[freimatz]

Zitat von p80286:

Mach es nicht!

dito von mir. Wenn du das absichern willst, dann mache das nahemöglichst bei der DLL.

Zur Ausgangsfrage noch: Von MS dafür vorgesehen ist/war OLE.
Das heißt jetzt aber keineswegs, dass ich das empfehle.