QT Konsolenapplikation mit Threads beenden

[msp]

Hallo zusammen!

Ich schreibe im Moment eine Qt Konsolen Applikation die mit mehreren Threads arbeitet.
Mein Problem ist, das ich nicht weiss wie ich die Threads ordnungsgemäß beenden kann wenn das Programm z.B. durch Strg + C oder durch einen Klick auf das "X" beende.

Mein Code sieht vereinfacht so aus:

Code: Alles auswählen

int main(int argc, char *argv[])
{
        QCoreApplication a(argc, argv);
        QMyThread t(&a);
        t.start();
        a.exec();

        //hier kommt mein Programm niemals an
        while(!t.isFinished());
        return 0;
}

Was mache ich falsch?

[Mani99]

Mit dem

Code: Alles auswählen

a.exec()

läuft die eventloop von qt weg und es kommt nie zum return 0!

Einfach a.exec() weglassen dann wird das programm beendet!

[msp]

Ich brauche die Eventloop aber, da in meinem Thread mit der Qt-Netzwerk-api gearbeitet wird.

Eigentlich soll sich das programm auch nicht von alleine beenden. Sondern nur durch das Klicken Aufs "X" oder durch Strg + c

[RHBaum]

Plattformunabhaengige loesung wirst dafuer sicher ned finden.

also:
Was verstehst du unter "sauber" beenden ? und warum soll das bei strg+c oder dem schliessen der konsole das passieren ? Normal ziehst du deinem programm damit die Basis unterm Hintern weg, und das BS selber sollte in der Lage sein, solcherart terminierten prozessen die ressourcen zu entziehen. Also in der Theorie.

Unter windows funktioniert das ganz leidlich. WIndows entzieht deinem prozess schon alle ressourcen und speicherleaks usw sollten ned auftreten. Das einzigste sind halt permanente ressourcen (files z.b.) die durch solche aktionen in nem undefinierten zustand versetzt werden koennten, inhaltlich gesehen.
Unter windows beendet man aber auch programme ned auf diesen weg.

unter linux siehts bissi anders aus. Ob das BS alle ressourcen wieder recyclen kann, wenn die prozesse terminiert werden und der prozess selber kein multiprozessing verwendet, k.a. aber ich geh stark von aus.
Nur werden bei Linux doch ab und an prozesse ueber das BS auf dem weg beendet (daemonen und das kill).

deshalb, welches BS iss bei dir der Fall ?

Ciao ...

[dama]

Für strg+c kannst folgendes verwenden:

benötigt: #include "Signals.h"

und dann das interrupt signal (SIGINT für ctrl+c) verwenden, um gesamte Applikation zu schliessen.

signal(SIGINT, QApplication::exit);


wenn probleme hast... am Besten überall (in alle Konstruktoren der threads etc.) einbauen, dann findest schon den richtigen platz ^^

[pfid]

Für strg+c kannst folgendes verwenden:

benötigt: #include "Signals.h"

und dann das interrupt signal (SIGINT für ctrl+c) verwenden, um gesamte Applikation zu schliessen.

signal(SIGINT, QApplication::exit);


wenn probleme hast... am Besten überall (in alle Konstruktoren der threads etc.) einbauen, dann findest schon den richtigen platz ^^

Einmal an der richtigen Stelle reicht...

Ganz davon ab, ist QApplication::exit() threadsafe? D.h. darf es aus einem Nicht-Mainthread-Kontext aufgerufen werden?

Und meinst du evtl. signal.h?

[dama]

hast recht, war ein s zuviel

#include "Signal.h"

Die statische QCoreApplication Methode exit() beendet den exec loop und sucht zuvor bzw. kennt ihren Prozess, welchen es nur einmal gibt.

Deine andere Frage verstehe ich nicht, zumal man ja nur den event-loop beendet... danach kann man ja noch agieren etc.

[pfid]

hast recht, war ein s zuviel

#include "Signal.h"

Die statische QCoreApplication Methode exit() beendet den exec loop und sucht zuvor bzw. kennt ihren Prozess, welchen es nur einmal gibt.

Deine andere Frage verstehe ich nicht, zumal man ja nur den event-loop beendet... danach kann man ja noch agieren etc.

Signale des Betriebssystems werden unter Unix bei Verwendung von POSIX Threads einem zufälligen Thread (sprich: auch nicht dem Mainthread) zugestellt, sofern ein Signal Handler angemeldet ist. D.h. es kann passieren, dass der Worker-Thread QApplication::exit() aufruft.

Daher die Frage, ob das geht, oder Probleme macht.