qtforum.de

Hi Leute,

ich bräuchte unbedingt eine Möglichkeit, alle anstehenden signal/slot-events in einem anderen thread abzuarbeiten... den thread bekomm ich ja durch thread() aber ich habe ja leider nur bei QCoreApplication/QApplication die Möglichkeit, processEvents aufzurufen...

Weiß da jemand ne Lösung?

QThread::exec() oder QEventloop::processEvents()

Mit QThread::exec() kann ich doch nur die Event-loop starten, nicht nochmal "anschubsen", die event loop läuft ja, nur will ich dem thread ein bischen zeit zum rechnen geben. Und für QEventLoop::processEvents() bäucht ich ne QEventloop, die ich aber nicht habe, und von nem thread kann man leider keine eventloop bekommen...

Wenn die Eventloop schon läuft - was gibts für ein Problem? Wenn der Thread rechnen soll, las ihn rechnen - wenn nichts zu rechnen ist lass ihn in der Eventloop laufen...

Dann muss ich wohl mal genauer werden ^^

Ich hab einen Thread in dem ich Netzwerk-I/O durchführe und andere Threads die mit diesem Thread kommunizieren um etwas zu senden/empfangen. Jetzt sendet einer dieser Threads ein Packet zum Netz-Thread und will dann auf eine Antwort warten (um Senden und empfangen in einer Funktion zu haben, quasi bekomme Antwort von Anfrage x). Nur wenn ich dann auf die Antwort warten will, muss ich das ganze mit ner While-Schleife machen, nur wenn ich in ner while-schleife bin, kann der andere thread nicht rechnen, da der Sender-thread die ganze cpu-zeit bekommt und somit die event-loop des Netz-Threads nicht aufgerufen wird.
Deshalb muss ich die Möglichkeit haben, dem Netz-Thread innerhalb einer Funktion Rechen-Zeit zu geben...

Busy wait sollte vermieden werden - den Grund siehst Du ja selbst. Auf eine Antwort warten würde man deshalb sinnvollerweise mittels Signal/Slot realisieren. Oder ggf. mit einem sleep(1) - aber dann geht z.B. das Eventhandling auch nicht in diesem Thread (ist natürlich die Frage ob man es an dieser Stelle überhaupt braucht)

Also hab ich keine Möglichkeit, eine Funktion zu haben, der man eine Frage gibt (die sie übers Netz sendet) und mir als Rückgabewert die Antwort gibt?

Wenn nicht, wär das aber ziemlich schlecht, weil das ja im Endeffekt meine Funktionen alle in zwei teilt und da ich viele Funktionen benutze, dass dann ziemlich unübersichtlich und in meinen Augen unnötig wird...

Ich habe Dir zwei solcher Möglichkeiten aufgezeigt - was willst Du mehr?

ok, ich könnte sleep(0) benutzen um aus dem aktuellen Thread quasi raus zu springen, das ganze halt in ner Schleife, das muss ich mal probieren... aber mit Signal/Slot kann ich doch nicht in eine Funktion springen, oder gibts da ne Möglichkeit, ich habs schon mit QWaitCondition probiert aber das funzt net so ganz, wie ich will...

Ich probiers dann mal, trotzdem bin ich der Meinung, solch ein Feature sollte in Qt verfügbar sein, das würde einiges vereinfachen...

Aber danke!

Was soll das für ein Feature sein? Busy wait? Das ist eher eine Unart. Und auf irgend etwas warten wird nunmal in Qt-Manier per Signal/Slot gemacht (damit solltest Du dich echt mal beschäftigen). Und wenn ich das nicht mag gibts ja immernoch QEventLoop.

Ich hab mich schon sehr gut damit beschäftigt, nur wenn man die Anforderung hat, Senden und Empfangen in der gleichen Funktion zu haben, die in einem anderen Thread ist, als der, der für das Netzwerk zuständig ist, ist das ein kleines Problem.

Und ich will kein busy wait als feature, sondern ein QThread::processEvents(), denn nicht nur in solch einer Schleife sondern auch in größeren Funktionen könnte dies nützlich sein, sonst wäre QCoreApplication::processEvents() ja auch völlig unnötig.

Da mein Programm, ein kleines bischen größer ist (mehrere tausend Zeilen code) und ein kleines bischen komplexer ist, als nur n mail-client oder so, ist eine trennung von senden und empfangen contraproduktiv, da dadurch rund 30-40 Funktionen betroffen wären und es eineiges komplizierter machen würde, als nötig.

Und wenn du meinst, man könnte Senden und Empfangen in einer Funktion mit Signal/Slots realisieren, dann wäre ich dir sehr dankbar, wenn du mir sagen könntest, wie.

Ok, zum x-ten mal - QEventLoop !!