Angepasster Fortune-Client -> Endlosschleife

[thebigear]

Hallo,

ich wollte gerne in mein Berechnungs-Programm die Möglichkeit schaffen die Ergebnisse per TCP zu übertragen. Dazu habe ich das Beispiel des threaded Fortune-Clients in mein Programm eingebaut. Das funktioniert wunderbar.

Wenn ich aber jetzt statt der statischen Fortunes, die in der Klasse "FortuneServer" angegeben sind durch meine Ergebnisse ersetzen will, dann läuft die Übertragung bei der zweiten Abfrage in eine Endlosschleife.

Hier mein modifizierter Code:

Code: Alles auswählen

void Gui_TcpServer::incomingConnection( int socketDescriptor ){
    /// angepasste stelle
    QString data = emit(getGuiData());

    /// dann kann ich den Thread eröffnen und die Daten übergeben!!
    Gui_MessageThread *thread = new Gui_MessageThread(socketDescriptor, data,this);
    connect(thread, SIGNAL(finished()), thread, SLOT(deleteLater()));
    thread->start();
    thread->quit();


}

Die Daten bekomme ich an der Stelle auch durch das Signal, ich rufe diese erstmal per Fortune-Client ab. Aber beim zweiten Drpcken auf "Get Fortune" gibt es wie gesagt eine Eindlosschleife?

Wo liegt der Fehler, oder kann ich die Daten so garnicht übergeben und wie müsste ich es dann machen?

Danke Ingo

[franzf]

Reduzier dein Problem, so dass es ein minimales kompilierbares Beispiel gibt. Ich seh aber hier schon zwei Sachen die böse ausgehen können (werden):

*) QString data = emit(getGuiData());
Du bist hier Multithreaded unterwegs, k.A. was das an Problemen mit sich bringen kann (wg. QueuedConnection). Tatsächlich kann einiges schief laufen, wenn mehrere SLOTS auf dieses SIGNAL connected sind - welcher return von welcher Funktion soll zurückgegeben werden?
Lösung: Mache dich mit der Funktionsweise von SIGNAL/SLOT vertraut und zerlege deine Logik in mehrere Funktionen.

*)thread->start(); thread->quit();
Aua... quit() stoppt die EventLoop. Damit werden deine Events nicht mehr verarbeitet. Das würde erklären, dass das erste SIGNAL noch in der Loop verarbeitet wird, die nächsten aber alle keinen Effekt mehr haben...

[thebigear]

Vielen Dank für die Kommentare.

*) QString data = emit(getGuiData());
...
Lösung: Mache dich mit der Funktionsweise von SIGNAL/SLOT vertraut und zerlege deine Logik in mehrere Funktionen.

Ich dachte, dass ich hier noch nicht multitreaded unterwegs bin, da ich doch erst danach einen neuen Thread erstelle.

Wie kann ich denn diese Logik noch kleiner zerlegen?

Der neue Thread soll nichts anderes machen, als die aktuellen Ergebnisse übermitteln.

Danke

[franzf]

Ich dachte, dass ich hier noch nicht multitreaded unterwegs bin, da ich doch erst danach einen neuen Thread erstelle.

Ich weiß leider nicht, was da sonst noch an connections an dem SIGNAL hängt, und vor allem auch nicht ob sonst noch andere Threads laufen (ich hab es angenommen). Der Punkt mit den mehreren SLOTS die auf das SIGNAL connected sein können bleibt ja.

Was mir halt komisch vorkommt, ist dass du das emit wirklich als normalen Funktionsaufruf mit return auffasst. Kannst du denn da nicht einfach direkt eine Methode aufrufen, ohne den Umweg über SIGNAL/SLOT?

Wie kann ich denn diese Logik noch kleiner zerlegen?

Das weiß ich nicht, da du nicht genügend Code zeigst. Wo liegen die SLOTS, die auf dein SIGNAL connecten?

Der neue Thread soll nichts anderes machen, als die aktuellen Ergebnisse übermitteln.

Wohin übermitteln? Brauchst du da wirklich einen Thread, oder reicht hier auch eine normale Funktion + SIGNAL? Was macht der Thread momentan?

Kannst du dein Problem nicht komprimieren und hier als Attachement (gepackt, ohne Binaries usw) anhängen?