Thread von außen beenden

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
maksimilian
User
Beiträge: 86
Registriert: Freitag 2. November 2018, 20:59

Hallo Ihr,

das Thema ist sicher schon oft behandelt worden. Die Situation bei mir ist folgende:
In einem Thread läuft ein kleiner TCP-Server basierend auf dem socket-Modul. Er wartet mit accept() auf den (einzigen) Client. Wenn das Skript, in welchem der Thread läuft, mit KeyInterrupt beendet werden soll, erfordert das aufgrund des blockierenden accept 2x Strg+C, um auch den Thread zu beenden. Es gäbe zwar die Möglichkeit den accept mit setblocking unterbrechbar zu machen, um dann z.B. ein threading.Event abfragen zu können, was den Nachteil hätte, ihn permanent in einer Zeitschleife aufrufen zu müssen.

Welche Konstruktion würde es erlauben, den Thread bei blockierendem accept von außen sauber zu beenden ?

maksimilian
Sirius3
User
Beiträge: 17749
Registriert: Sonntag 21. Oktober 2012, 17:20

Warum hast Du überhaupt einen Thread?
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

maksimilian hat geschrieben: Sonntag 14. März 2021, 17:11 Welche Konstruktion würde es erlauben, den Thread bei blockierendem accept von außen sauber zu beenden ?
Die Frage hast du dir im Prinzip schon selbst beantwortet:
Es gäbe zwar die Möglichkeit den accept mit setblocking unterbrechbar zu machen, um dann z.B. ein threading.Event abfragen zu können, was den Nachteil hätte, ihn permanent in einer Zeitschleife aufrufen zu müssen.
Eine Alternative wäre dazu noch ein timeout auf dem Socket zu haben aber das Prinzip dass der Thread kooperiert bleibt.

Es gibt zwar Möglichkeiten einen Thread von außen zu beenden aber dass ist nichts was auch nur annähernd sauber wäre. Stell dir z.B. mal vor der Thread hält gerade ein Lock (muss nicht unbedingt dein Code sein kann auch ein Lock irgendwo im Interpreter oder so sein) und du killst den Thread. Du bist da eigentlich sofort im Bereich von potenziellen Deadlocks und undefiniertem Verhalten.
maksimilian
User
Beiträge: 86
Registriert: Freitag 2. November 2018, 20:59

Sirius3 hat geschrieben: Sonntag 14. März 2021, 17:44 Warum hast Du überhaupt einen Thread?
Wegen der notwendigen Bereitschaft, auf andere Ereignisse als die vom Client reagieren zu müssen. Für die Fragestellung spielt das aber keine Rolle.
maksimilian
User
Beiträge: 86
Registriert: Freitag 2. November 2018, 20:59

DasIch hat geschrieben: Sonntag 14. März 2021, 18:30 Eine Alternative wäre dazu noch ein timeout auf dem Socket zu haben aber das Prinzip dass der Thread kooperiert bleibt.
/quote]

Das wäre immer noch besser als die Lösung mit setblocking. Wie sieht da die Syntax aus ?
Sirius3
User
Beiträge: 17749
Registriert: Sonntag 21. Oktober 2012, 17:20

@maksimilian: natürlich spielt das für die Fragestellung eine Rolle. Wenn es möglich ist, würde man nämlich erst gar nicht mit Threads anfangen.
Asynchrone Programmierung wäre da so eine Alternative.

Ansonsten einfach Serversocket schließen.
maksimilian
User
Beiträge: 86
Registriert: Freitag 2. November 2018, 20:59

Das Thema hat sich erledigt.
Antworten