Mehrere UI Threads in einem Prozess
-
Was ist falsch dran, wenn sie keine GUI haben?
-
Nix, ich habe außer Application.Run keine Möglichkeit in C# (Compact Framework) gefunden, einen Thread mit MessageQueue zu erzeugen. (Würde mir wirklich gefallen wenn es da einen besseren weg gäbe. Beim ersten Problem hing aber leider eine Form drinn, die Initialisiert werden will, da komme ich nicht drum herum :o( Thx für den Link!)
-
Knuddlbaer schrieb:
Thx für den Link!
Beim Analysieren, wie er das macht hab' ich viel gelernt.
Ich kann so ne Menge (HTTP-)threads erzeugen ohne mich um irgendeine Synchronisation kümmern zu müssen.
Wie er sagt: "The best synchronisation is no synchronisation."
Mr.Newcomer hat's schon drauf...
-
Ja, Syncronisierung ist aber auch nicht unbedingt das Problem, um das es hier geht. (Dennoch ist der Link interessant.)
-
Knuddlbaer schrieb:
Ja, Syncronisierung ist aber auch nicht unbedingt das Problem, um das es hier geht. (Dennoch ist der Link interessant.)
Ja, hab' ich mir nach dem posten auch gedacht.
Es ist aber das beste Beispiel für UI threads, das ich kenne.
Hier geht's eher um die Verwirrung von "UI threads" und "UI threads, die die GUI verwenden"...
-
@Knuddlbaer: Ein "es geht nicht weil" kann ich nicht liefern. Im Gegenteil, ich bin fast davon überzeugt dass es sehr wohl geht (und auch "OK" ist), auch mit mehreren Threads die wirklich sichtbare und klickbare Fenster haben. Zumindest solange diese Fenster nicht irgendwie mit Parent/Child zusammengeknotet werden.
Gründe die im Allgemeinen dagegen sprechen kann ich dir aber schon nennen, obwohl ich davon ausgehe dass du diese bereits kennst:
-
Viele GUI Programmierer rechnen einfach nicht damit. Was dazu führt dass sie Code schreiben der damit nicht klar kommt (statische Variablen ohne "lock" etc.). Was logischerweise zu Problemen führen kann wenn man es doch macht.
-
Wenn die verschiedenen GUI Threads Fenster von anderen GUI Threads kennen kann man schnell einen Deadlock basteln, nämlich z.B. wenn 2 Threads gleichzeitig ein "Invoke" auf ein Control des jeweils anderen Threads machen.
-
AFAIK gibt es einige Fallstricke wenn Fenster die von unterschiedlichen Threads bedient werden mit Parent/Child zusammengeknotet werden. Genaues dazu kann ich dir leider auch nicht sagen, ich weiss nur dass ich das sicher nie machen werde, ausser es muss unbedingt sein, und in dem Fall würde ich mich auf einige Probleme gefasst machen.
Ansonsten, wie gesagt, unabhängige Threads die halt jeder ihre paar Fenster haben und bedienen - wüsste nicht wieso das in die Hose gehen sollte. Versteckt macht das COM ja auch nicht anders wenn man in einem Prozess mehrere single threaded Apartments hat (was ja nicht verboten ist). Da gibt's dann auch ein fesches (verstecktes) Message-Fenster für jeden Thread über das das ganze Event-Dispatching läuft.
Inwieweit das .NET Framework damit klar kommt kann ich leider auch nicht sagen. Dass Win32 damit grundsätzlich kein Problem hat weiss ich, da ich selbst in einer Applikation ein verstecktes Message Fenster verwende welches seinen eigenen Thread hat. Und das funktioniert sehr gut.
-
-
Müsste ich Punkt 2 nicht auch innerhalb eines einzigen UI Threads erreichen können ?
-
Nö, wüsste nicht wie. Invoke sollte IMO den delegate einfach "normal" ausführen, ohne irgendwelche Message Geschichten, wenn man es bereits im "passenden" Thread aufruft. Also einfach als Unterfunktion.
In Win32 geht es zumindest, also wenn man mit SendMessage arbeitet.
Oder übersehe ich da jetzt irgendwas?
-
Den von Dir angesprochenen Punkt finde ich jetzt sehr von interesse.
Vllt. hilft mir erst mal die Gegenfrage weiter: Warum sollte ein Deadlock auftreten wenn es zwei UI Threads sind ?
Rufe ich Invoke aus einem fremden Thread auf, die UI ist aber mit etwas anderem beschäftigt (und wartet vllt. auch den externen Thread), dann kassiere ich mir auch bei diesem Invoke ein Deadlock.
Mir fehlt jetzt aber die Phantasie, wo ein Deadlock herkommen könnte, wenn ich 2 UI Threads habe (abgesehen von Deadlocks die ich auch in einem normalen Thread kassieren kann.)
In diesem Punkt könnte das (für mich) wichtigste vergraben liegen was ich übersehe.
(Wenn ich mir den Punkt2 mal nach ausschlafen durchlese, ist das was Du beschreibst eigentlich ein klassischer Deadlock. Also kein Problem eines speziellen UI Threads.)
-
Richtig, ist ein klassischer Deadlock. Invoke ist halt so eine Funktion die oft verwendet wird ohne gross nachzudenken, von daher denke ich dass die Gefahr hier evtl. etwas grösser ist.
Du hast wahrscheinlich Recht, ist im Prinzip bloss ein "Unterpunkt" von Punkt 1).
-
Bei Fachdiskussionen hab ich nur ungern recht. Denn wenn man Unsinn schreibt und verbessert wird lernt man mehr. (Und wenn es dann richtig peinlich war, vergisst man es auch nicht mehr ;o) Hier gab es aber schon viel zu lernen
~Mit Threading bin ich noch nicht so erfahren. Nach Deadlocks hab ich da auch schon suchen müssen, Die Theorie hört sich einfach an zu diesem Thema, aber die Praxis schaut anders aus.~
