Wie nicht kooperative Pthreads killen? [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie nicht kooperative Pthreads killen?

nobody0

12-02-2005, 20:21

In einem Pthread habe ich eine Stelle (open), an der er hängen bleiben kann und deshalb gekillt werden muß.
Über pthread_cancel oder pthread_kill kann ich den Thread aber nicht killen; er hängt weiterhin.
Irgendwelche Vorschläge? :confused:

rgubatz

14-02-2005, 17:20

Hallo,
wie wäre es mit pthread_exit() ?

Gruss Rene

nobody0

14-02-2005, 17:46

Hallo,
wie wäre es mit pthread_exit() ?

Gruss Rene

Das killt nur den aufrufenden Thread, also den falschen ...
Das Problem ist, dass der betreffende Thread beim open auf ein Device hängen kann; das wirkt wie for( ; ; ) ; .
Danach kann er nicht selber terminieren.

Joghurt

14-02-2005, 20:15

Wie wäre es mit
kill(PID,9);?

nobody0

14-02-2005, 23:59

Wie wäre es mit
kill(PID,9);?

Damit killt sich das Programm selbst, aber es soll nur der Thread gekillt werden.

nobody0

15-02-2005, 03:22

Also ich habe es hinbekommen mit einem Signal-Handler von main und einem vom betreffenden Thread. Über ein pthread_kill (thread1, SIGUSR1); vom Timeout-Thread funktioniert das Killen nun sauber.

panzi

15-02-2005, 16:34

Das killt nur den aufrufenden Thread, also den falschen ...
Das Problem ist, dass der betreffende Thread beim open auf ein Device hängen kann; das wirkt wie for( ; ; ) ; .
Danach kann er nicht selber terminieren.
Gibt's da net ne alternative open funktion, so ala tryopen, die schaut ob's öffnen blockieren würd, un wenn ja einen fehlercode liefert? dan hast du das problem garnet.

nobody0

15-02-2005, 19:18

Gibt's da net ne alternative open funktion, so ala tryopen, die schaut ob's öffnen blockieren würd, un wenn ja einen fehlercode liefert? dan hast du das problem garnet.

Jemand meinte, dass es mit "nicht blockierendem" Öffnen geht, aber ich weiß nicht, wie das gehen soll. Bisher konnte ich nur etwas zu nicht blockierendem Lesen/Schreiben finden.

panzi

15-02-2005, 20:37

nobody0

15-02-2005, 21:24

Also wenn du open() verwendest, kanns't du O_NONBLOCK als flag angeben:
http://www.opengroup.org/onlinepubs/009695399/functions/open.html

Ich denk das wird den gewünschten Effekt ergeben, musst dir anschaun.

Achso, das ist gemeint, danke.
Ich habe das eingebaut, aber damit wäre das Problem wohl nur verschoben, denn ich mußte einige Male einen USB-RS232-Adapter abziehen und neu einstecken um den zu resetten und wieder verwenden zu können. Bei einem abgestürzten Adapter und erfolgreichen open mit Nonblock könnte dann nicht geschrieben werden (das zeigt dann der Rückgabewert von write) und nicht gelesen werden (select liefert timeouts).
Weil ich den Fehler jetzt nicht reproduzieren kann, kann ich das nicht überprüfen.
Das ist aber nicht wichtig, weil die Threads nicht schaden und ich alle Rückgabewerte, insbesondere die von open, ioctl, write, read und select überprüfe.

nobody0

16-02-2005, 09:31

Also nach einem halben Tag "Dauer-"Betrieb ist mir der noname-USB-RS232-Adapber wieder abgestürzt und damit funktioniert noch das nicht blockierende Öffnen. Anschließend funktioniert auch tcflush, aber beim tcsetattr bleibt die Funktion hängen; sie kommt nicht bis zum nachfolgenden ioctl für den exclusiv mode (damit nur ein Programm zur Zeit die Schnittstelle belegt).

Kurzgesagt ist der Timeout-Thread und die Interprozess-Kommunikation über die Signal-Handler doch nötig.