![]() |
Threadlogik Problem
Hallo,
ich steht grad auf dem Schlauch, ich hab ein kleines Logikproblem, bezüglich 2'er Threads... Der 1. Threads muß immer an sein, es sei denn der User klickt auf Stop... So eine Art WatcherThread... Der 2. Thread ich nenn Ihn mal WorkerThread, soll nur dann aktiv sein, wenn der 1. Thread etwas bestimmtes gefunden hat, dann soll der Workerthread etwas ausführen uns zwar nur einmal, und sich dann selber beenden. Das Problem ist, wenn ich das mal auf folgendes Szenario abbilde: 1. Thread findet ein bestimmtes Fenster, jetzt ruft er den 2. Thread auf, dieser sendet eine Nachricht, an das vom Thread 1 gefundene Fenster, jetzt muß ich ja irgendwie sicherstellen, das wenn die Nachricht versendet wurde, der 2. Thread sich beendet. Mir ist nur unklar woran ich das festmachen soll, weil ja der 1. Thread den 2. Thread created wenn das Fenster sichtbar ist. Das wäre ja dann ne art Endlosschleife? Was ich vermeiden muss irgendwie ohne den 1. Thread zu killen. Ich hoffe das mir jemand in mein Chaos folgen kann und einen Tip für mich hat... Viele Grüsse s! |
Re: Threadlogik Problem
Warum soll das eine Endlosschleife sein?
Vom Verlauf her sieht das doch so aus:
Code:
Wenn du beim WorkerThread FreeOnTerminate auf True setzt, dann gibt er sich ja selbstständig frei, wenn die Execute-Methode rum ist und er sich somit terminiert.
1. Thread läuft in einer (abbrechbaren) Endlosschleife und sucht ständig nach so einem Fenster
- - \/ 1. Thread findet ein Fenster, erstellt und startet einen WorkerThread - - \/ Der Worker-Thread arbeitet nicht in einer Endlosschleife, sondern sendet eine Nachricht (WM_??) an das Fenster und dann ist die Execute-Methode vorbei - - \/ 1. Thread bekommt, wenn benötigt, über das OnTerminate Ereignis mit, wenn der WorkerThread fertig ist Ist damit dein Problem geklärt, oder wohin solls genau gehen? Gruß alias5000 |
Re: Threadlogik Problem
Zitat:
Der 1. Thread muss ja unendlich nach einem Fenster suchen, wenn diese gefunden wird den Workerthread starten, dieser sendet die Nachricht und soll sich beendet wenn die Nachricht versendet wurde, was aber wenn das Fenster Fremdfenster nicht geschlossen wurde? Thread1 startet ja dann wieder Thread2? Genau das ist ja das Problem. Szenario 2 Thread1 findet das Fenster, Worker wird gestartet sendet die Nachricht und würde beendet werden, Fremdfenster wurde geschlossen. Fremdfenster wird erneut aufgerufen, also wieder alles von vorne! Das ist mir völlig unklar logiktechnisch... Ich zeigs mal per Code vielleicht wirds dann deutlicher:
Delphi-Quellcode:
Gruss
constructor TMozWatchDogThread.Create;
begin inherited create(true); freeOnTerminate := true; Priority := tpLowest; end; destructor TMozWatchDogThread.destroy; begin inherited destroy; end; procedure TMozWatchDogThread.Execute; begin while not(Terminated = true) do begin // Suche Fenster wenn handle > 0 dann // StarteWorkerThread; // hat workerthread nachricht gesendet und ist fremdfenster geschlossen, // dann alles von vorne, hat worker nachricht gesendet aber fenster noch offen // dann nicht erneut nachricht an fremdfenster senden! end; end; { TMozWatchDogWrokerThread } constructor TMozWatchDogWorkerThread.create; begin inherited create(true); freeOnTerminate := true; Priority := tpLowest; end; destructor TMozWatchDogWorkerThread.destroy; begin inherited destroy; end; procedure TMozWatchDogWorkerThread.Execute; begin // sende nachricht an fremdfenster, dann beende dich selber end; s! |
Re: Threadlogik Problem
Das ist dann eher eine Frage der Anwendungslogik.
Was genau soll sie machen und wie soll sie auf bestimmte Szenarien reagieren? Gerade Szenario 1 würde ich mir erstmal ohne eine konkrete Umsetzung überlegen, sondern erstmal, was das gewünschte Verhalten der Anwendung ist. Dann ist die Umsetzung einfacher. Beispiel: Wenn deine Mozilla-Software (liege ich richtig?) nicht geschlossen wird, trotz WM_CLOSE, oder was du sendest, dann musst du dir überlegen, wie du damit von der Anwendungslogik her umgehst. Soll eine MessageBox hochgehen, wenn die Anwendung nicht innerhalb von 10 Sekunden geschlossen wird,...? Sowas in die Richtung Gruß alias5000 |
Re: Threadlogik Problem
Nochmal anders erklärt, sagen wir der User öffnet in Mozilla den speichern dialog, worauf Thread 1 lauscht, sollte das der Fall sein soll Worker ne message in den Dialog von Moz posten, was auch passiert, nur kann ich den Dialog ja nicht killen, weil der User eventuell noch nen anderen Pfad wählen will oder sonstiges daher prüfen ob Handle des Dialogs > 0 ist
|
Re: Threadlogik Problem
Ja gut, aber im 1. Thread wirst du ja sehen, ob gerade ein Speicherndialog mit einem bestimmten Handle offen ist, oder nicht.
Du kannst dann ja einfach im 1. Thread ne Bool-Variable benutzen, die auf true gesetzt wird, wenn ein neues Fenster gefunden wurde und dazu ein Thread erstellt wurde. Der Workerthread verrichtet dann seine Arbeit und beendet sich. Solange die Boolean-Variable zu dem spezifischen Handle true ist, wird kein neuer Thread erstellt. Wenn dann der 1.Thread feststellt, dass das Handle dieses gefundenen Dialoges = 0 ist, setzt er die Bool-Variable zurück und würde somit später wieder einen Workerthread erstellen, wenn ein neuer Dialog geöffnet würde Verstanden, was ich meine? Gruß alias5000 |
Re: Threadlogik Problem
Theretisch ja, nur praktisch hat auch das nicht funktioniert, frag mich nicht warum, irgendwie beendet sich der worker ned :-(
|
Re: Threadlogik Problem
Code?
|
Re: Threadlogik Problem
Hi,
Zitat:
aber der WatchDogThread das Fenster immer wieder findet und immer neue WorkerThread startet? Das will wohl auch alias5000 mit dem Boolean verhindern. |
Re: Threadlogik Problem
Hi,
Wieso willst Du überhaupt nur um eine Nachricht zu senden, eine extra Thread starten ? Ich sehe da keinen Sinn drin, wenn der WatchThread sowieso erst wissen muss, ob das geklappt hat oder nicht, kann er's ja auch selber machen. Das vereinfach die Logik, macht das Programm schlanker und effizienter (ein extra Thread heißt ja auch extra Verwaltung) und dich glücklicher ;-) Gruss |
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:19 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz