QTcpServer bleibt nach Programmabbruch bestehen

Alles rund um die Programmierung mit Qt
Antworten
KartoffelKiffer
Beiträge: 101
Registriert: 27. Februar 2008 15:59

QTcpServer bleibt nach Programmabbruch bestehen

Beitrag von KartoffelKiffer »

Hallo,

ich arbeite mit Qt 4.7.3 unter Windows XP und Visual Studio 2008.

Das Programm baut einen QTcpServer auf und arbeitet mit QProcess, der ein Programm startet, bis das Eltern-Programm beendet wird.

Wenn ich das Programm allerdings hart abschieße (TaskManager -> Prozess beenden), so bleibt das Kind-Programm und der Port am Leben, sodass es mir nicht möglich ist, das Programm erneut starten und einen Server aufbauen zu lassen.
Ebenso können sämtliche Clients weiterhin eine Verbindung zu dem Server aufbauen und darauf ohne Fehler schreiben.

startDeteched kann ich nicht nehmen, da ich Signale und den Standard-Output- und Error-Kanal von QProcess verwende.

Ist für diese Art von Problem eine Lösung in Sicht, oder werde ich mich damit abfinden müssen, dass der Eltern-Prozess am Leben erhalten wird, auch wenn er eigentlich abgeschossen wurde?



Grüße, KK
brax
Beiträge: 208
Registriert: 11. Mai 2010 11:22

Re: QTcpServer bleibt nach Programmabbruch bestehen

Beitrag von brax »

Beim Beenden über den TaskManager musst Du "End Process Tree" (k.a. wie das im deutschen Windows heißt) benutzen, dann werden auch die Kindprozesse getötet. Es ist normal, dass diese sonst als "Waisen" übrig bleiben. Auf der Konsole würdest Du übrigens "taskkill /T" dafür benutzen.

Eine andere Frage: warum musst Du das Programm "hart abschießen", um es zu beenden? Wenn Du es regulär beendest, könntest Du den QProcess doch beim Beenden auch abschießen.

Eine weitere Möglichkeit wäre, dass Du in dem gestarteten Programm periodisch abfragst, ob das Eltern-Programm noch läuft. Dazu könntest Du ihm die PID beim Start mitgeben (qApp->applicationPid()) und dann periodisch über die WIN32 Api (soweit ich weiß bietet QT keinen Weg) abfragen, ob ein Prozess mit der PID existiert. Beispiel:

Code: Alles auswählen

qint64 parentPID = // aus den kommandozeilenparametern holen

bool checkParentRunning() {
    HANDLE proc = OpenProcess(PROCESS_VM_READ, 0, parentPID); // liefert 0, falls parentPID ungültig
    pidExists = proc;
    CloseHandle(proc);
    return pidExists;
}
KartoffelKiffer
Beiträge: 101
Registriert: 27. Februar 2008 15:59

Re: QTcpServer bleibt nach Programmabbruch bestehen

Beitrag von KartoffelKiffer »

brax hat geschrieben:Beim Beenden über den TaskManager musst Du "End Process Tree" (k.a. wie das im deutschen Windows heißt) benutzen, dann werden auch die Kindprozesse getötet. Es ist normal, dass diese sonst als "Waisen" übrig bleiben. Auf der Konsole würdest Du übrigens "taskkill /T" dafür benutzen.

Eine andere Frage: warum musst Du das Programm "hart abschießen", um es zu beenden? Wenn Du es regulär beendest, könntest Du den QProcess doch beim Beenden auch abschießen.

Eine weitere Möglichkeit wäre, dass Du in dem gestarteten Programm periodisch abfragst, ob das Eltern-Programm noch läuft. Dazu könntest Du ihm die PID beim Start mitgeben (qApp->applicationPid()) und dann periodisch über die WIN32 Api (soweit ich weiß bietet QT keinen Weg) abfragen, ob ein Prozess mit der PID existiert. Beispiel:

Code: Alles auswählen

qint64 parentPID = // aus den kommandozeilenparametern holen

bool checkParentRunning() {
    HANDLE proc = OpenProcess(PROCESS_VM_READ, 0, parentPID); // liefert 0, falls parentPID ungültig
    pidExists = proc;
    CloseHandle(proc);
    return pidExists;
}
Hallo brax,

das Beenden über den TaskManager war bloß ein Beispiel für einen unnormalen Programmabbruch, den ich simulieren wollte. Ebenso könnte sich das Programm durch einen Pufferüberlauf selbst beenden.

Die Idee mit der zyklischen Abfrage klingt gar nicht so verkehrt, auch wenn ich eigentlich Windows außen vor lassen wollte.

Ich könnte auch die Standard-Kanäle dazu nutzen, um ein ewiges Ping-Pong aufzubauen. So wäre wenigstens der OpenProcess und CloseHandle-Krams raus.

Allerdings ist das etwas Zeit intensiver, weshalb ich gehofft hatte, es gibt eine bessere Lösung.



Gruß, KK
Antworten