C++ und SIGTERM usw.; wie funzt das eigentlich

Zitat

Doch irgendwie bringt mich das alles nicht so recht weiter. Muss ich dem Thread irgendwie ein SIGTERM schicken damit der alles stehen und liegen lässt und sich beendet? Was ist dann mit den geöffneten Handels?

Ja, musst du. Der aufrufende Thread muss diesen killen. Du hast auch wegen des Pollings keine andere Möglichkeit. Ich muss zugeben, dass ich mir Threads in Linux noch nie angeschaut habe, aber funktionieren müsste das so, dass wenn der Thread gestartet wird, du ein Handle auf diesen erhälts, damit sollte sich dann der Thread auch wieder mit einer Funktion ala KillThread(Handle vom Thread) beenden lassen. In deinem Beispiel dürfte das einfache Killen des Threads auch keine Probleme bereiten, da du ja keine Files beim beenden Speichern möchtest, so wie es VDR macht...

Gruß
Dagget

Hi,

Warum nicht per timeout = 250ms intervallweise warten ?

while(active)
{
    rc = poll(pfd, 1, 250);
    if(rc > 0) //Success
    {


    } else if(rc == 0) { //Timeout bzw. fd ungültig


    } else { // failed


    }




}

z.T. SIGTERM müsstest Du einen Signalhandler anlegen, wie es im glcdbase/showpic gemacht wurde.

static volatile bool stopProgramm = false;




static void sighandler(int signal)
{
	switch (signal)
	{
		case SIGINT:
		case SIGQUIT:
		case SIGTERM:
			stopProgramm = true;
	}
}




...


	signal(SIGINT, sighandler);
	signal(SIGQUIT, sighandler);
	signal(SIGTERM, sighandler);
	signal(SIGHUP, sighandler);


        while (!stopProgramm)
	{
...

Aber bist Du sicher das per signal ein Thread selektiv gestoppt werden sollte !?
Ich bevorzuge obrige Methode des Verzicht auf unendliche Wartezeiten...

Andreas

Ich hab das so verstanden, das poll() die wartende Funktion ist in der das eigentliche polling in einer Schleife stattfindet. Sonst ist deine Variante natürlich sinnvoller.

In thread.h habe ich folgendes gefunden, um Threads "hart" zu beenden:

void Cancel(int WaitSeconds = 0);
       ///< Cancels the thread by first setting 'running' to false, so that
       ///< the Action() loop can finish in an orderly fashion and then waiting
       ///< up to WaitSeconds seconds for the thread to actually end. If the
       ///< thread doesn't end by itself, it is killed.

Generell ist die Methode, poll() mit Timeout zu verwenden, die bequemste. Es gibt aber noch eine weitere Methode, um den Thread auch ohne Timeout schnell zu beenden: poll() kehrt auch bei ankommenden Signalen zum Aufrufer zurück, mit EINTR-Fehlercode. Senden kann man solch ein Signal mittels pthread_kill().

Gruß,

Udo

Hi,

Threads und Signale sind nicht ganz so einfach zu programmieren. Man muss einen Thread für den Empfang der Signale bestimmen. Ansonsten weiß man nicht, an welchen Thread das Signal geschickt wird!

Einzelne Thread kann man mit einem pthread_kill terminieren. Ist aber normalerweise nicht nötig, wenn man ein saubers Konzept hat.

Stirbt der Hauptthread (der Teil, in dem int main (argc, argv) steht), dann sterben auch alle erzeugten Threads. Alle "Handles" (wohl meistens sockets) werden dabei geschlossen.

Darüber gibt es sehr interessante Bücher.

Viele Grüße
KdF

Aus meiner Sicht ist es die sauberste Lösung, eine Meldung zu definieren, die zum Beenden des Threads führt. Das externe Töten des Threads ist zwar möglich, aber aus meiner Sicht eine sehr unsaubere Vorgehensweise.

Beim Beenden einer Applikation mag das ja noch angehen, jedoch nicht wenn man das zur Laufzeit macht (Beispiel: VDR->pluginloader-Plugin). Durch das externe Killen ist nicht sichergestellt, das alle Resourcen freigegeben wurden, da diese an die Applikation und nicht an den Thread gebunden sind. Nebeneffekte können zum Beispiel sein, das Datenbank-Sessions nicht mehr zugeteilt werden oder bestimmte Devices nicht mehr geöffnet werden können, weil der Treiber bereits ein exklusives Handle vergeben hat. Das kennt dann keiner mehr, aber der Treiber kann das nicht wissen.

Sauber wäre das Definieren einer Ausstiegsmeldung. Wenn jetzt jemand den Thread nach Hause schicken will, wird die Meldung abgesetzt und anschließend auf das Ende gewartet.

void setExitRequest(int code)
{
    sendMessage(new ThreadExitRequest(code));
    join(); // warte bis das OS den Thread entsorgt hat
}

Innerhalb des Threads führt das Aufreten der entsprechenden Methode dann zum Setzen der Ausstiegsbedingung und damit zum Threadende.

Das Weglassen des join() ist aus meiner Sicht auch wieder unsaubere Programmierung, da hier mit einem undefinierten Zustand gearbeitet wird. Keiner kann sagen ob beim bereits alle Resourcen frei sind, oder ob irgendwas noch unterwegs. Das lädt zu einer zeitintensiven Fehlersuche geradezu ein.

dierk