qtforum.de

Im Mandelbrot-Beispiel wird nicht auf eingehende Signals eingegangen. Es wird nur im eigenen Loop was berechnet....das reicht mir aber nicht. vielleicht sollte ich es mal so erklären,, wird eventuell klar was ich machen möchte. Akteure:(Threads) Sammler (Producer) Consumer0 Consumer1 ConsumerN-1 GUI...

ich glaub ich habs: (noch nicht getestet) processEvents run() { while(1) { if(flag) do_sth(); QEventloop::processEvents() } } Ich glaub es reicht aus wenn ich statt exec(), regelmäig processEvents() aufrufe. Was meint ihr? - So würde meine eigene Schleife mein FLAG überprüfen und die Daten verarbeit...

Schon klar, dass es ne endlosschleife ist. Ich brauche aber meine eigene Endlosschleife !?!? Oder wo kann ich exec sagen, dass es in gewissen Abständen ein Variable überprüfen soll und do_sth() ausführen soll. edit: der thread bekommt Daten zugeschickt,..überprüft von mir aus ein Flag und macht was ...

Danke für deine recht ausführliche Beschreibung. Jedoch hilft mir das nicht so ganz, denn ich brauche auch exec(). - Signale müssen in die Threads rein und raus. (daher exec()) - run darf nicht beendet werden, Threads sollen nur pausiert werden und später weiterlaufen (das pausieren eventuell mit se...

aha,

werde es noch ausprobieren aber....

ist es nicht so, dass wenn ich einmal exec erreiche nicht mehr zu der oberen schleife zurückkomme ohne den ganzen thread zu beenden und noch einmal neuzustarten???

würde schon gerne den thread länger leben lassen...

ok das mit dem Flag ist logisch. run(){ exec(); } Für die Signal/Slot Verbindungen, abgehend oder einkommend ,brauche ich exec(). D.h. in meiner run() kann ich schlecht eine Endlos-Schleife laufen lassen, weder vor exec oder nach exec. Eine Empfehlung wie ich / wo ich mein Flag überprüfen soll?

in den slots wollte ich kaum etwas machen, also recht minimal halten. Sagen wir mal ich übertrage meine Daten via Signal und im Slot speichere ich sie lokal z.B. in ein Array. Jetzt muss ja mein Thread X, der die Daten bekommen hat informiert werden "Es liegen Daten vor" Dafür müsste ich i...

Hi, Sachlage: Ich habe drei Threads, der eine ist der Datensammler, die anderen die Konsumenten. Wenn der Sammler die Daten bereit hält schiebt er den Konsumenten mit kosument->getData() die Daten und informiert sie mit indiv. Signalen. dass daten anliegen. So wie ich das verstanden habe sind beide ...

ich verwende schon WaitForMultipleObjects in Verbindung mit meiner RS232 Kommunikation. Ich habe ein Thread,das auf Daten (RS232) wartet. Wenn nun aber jemand das Programm beendet , soll "WaitForSingleObject" auch signalisiert werden, damit es nicht unnötig weiter auf Daten wartet und bloc...

Hi,

ich bräuchte für die obige Win32 Funktion einen HANDLE von meinem QThread.
In der Doku steht, dass diese Funktion für interne Sachen genutzt wird.
Kann mir das jemand bestätigen?

Ich möchte, dass WaitForSingleObject auf meinen Thread wartet.

Gruß
diddely

Hey Danke! Das ist es...anstatt immer wieder ptr weiterzureichen ist dies eine ganz gute alternative. Zu blöd, dass ich nicht selber darauf gekommen bin. Werde es mir mal anschauen und meinem Programm-Design anpassen. Zwischen Master und Worker Threads werde ich es aber nicht einsetzen. Da reicht sc...

Ok danke! Um es nochmal zu wiederholen: Der Master-Thread würde die zu verteilenden Daten abholen, dann würde es sich den richtigen Thread aussuchen und mit einem worker .get_work(data) die Daten übergeben. (Oder wie empfohlen mit Signal/Slot) Bei Signal/Slot müsste ich aber für jeden worker einen i...

Ok, meine Aussage bezieht sich nicht auf die GUI. Wirklich nur das "Master-Worker-Modell". Master, der die Arbeiten verteilt...die Arbeiter,..die die Arbeit verrichten. Gut...ich werde die Worker dann im Master(Verteiler)-Thread erzeugen. Wie soll ich am besten die Daten vom Master an die ...

stehe gerade auf dem Schlauch.
Also ist es nicht empfehlenswert worker-threads im Master zu erzeugen?

Meine Aussage bezieht sich auf diesen Beitrag:
http://qtforum.de/forum/viewtopic.php?t ... ht=qthread

Imho ist es ein Designfehler wenn ein Thread einen weiteren erzeugt.