In diesem Teil gibt es ein paar mehr Details zu UNIX-Signalen bzw. wie einige Funktionen

auf Signale reagieren.

Dafür fangen wir mit der Fork-Funktion an.

Wenn ein Fork ausgeführt wird, wird ein neuer Kind-Prozess erstellt und der Kind-Prozess

ist ein Ebenbild des Eltern-Prozesses mit Ausnahme der PID.

Was dabei mit vererbt wird, ist also auch die Signalbehandlung und die Signalmaske.

Das bedeutet, alle Signale, die in der Signalmaske des Eltern-Prozesses blockiert sind, sind

auch im Kind-Prozess blockiert.

Gleichermaßen gilt dieselbe Signalbehandlung für die Signale.

Das heißt also, wenn Signale aufs Gegner gesetzt sind, sind sie auch im Kind aufs Gegner

gesetzt oder wenn eine eigene Signalbehandlung für ein Signal eingesetzt wurde, gilt dies

auch für das Kind.

Ein bisschen interessanter wird es, wenn nun einer der beiden Prozesse versucht ein

EXEC auszuführen.

Durch den Aufruf von EXEC wird ein neues Programm geladen.

Das bedeutet, der Inhalt des Adressraums wird durch den ersetzt, den das neue Programm

mit sich bringt.

Hier wird mit der Signalmaske und der Signalbehandlung anders verfahren.

Die Signalmaske bleibt weiterhin erhalten.

Das heißt, der neu geladene Prozess blockiert dieselben Signale wie der vorherige.

Anders sieht es aus mit der Signalbehandlung.

Wurde die Signalbehandlung auf SIG default oder auf SIG ignore gesetzt, wird auch dies

für den neu geladenen Prozess beibehalten.

Wenn aber die Signalbehandlung auf eine eigene Behandlungsroutine gesetzt wurde, dann wird

diese zurück auf SIG default gesetzt.

Der Grund dafür ist, dass durch das EXEC der Adressraum des alten Programmes ersetzt

wurde.

Damit sind alle Funktionen, die das vorherige Programm hatte, nicht mehr verfügbar.

Also wären alle Funktionszeiger, die ehemals gesetzt waren für die Signalbehandlung, nicht

mehr gültig, da jetzt nicht gewiss ist, worauf sie zeigen.

Die nächste Funktion ist WaitPID.

Mit WaitPID können wir Zombieprozesse auffangen und dabei optional warten.

Dabei können wir entweder auf alle Kindprozesse warten oder auf ein beliebiges.

Desweiteren können wir das Verhalten noch durch die Optionen ändern.

Zum Beispiel können wir mit der Option wUntraced einmal setzen, dass die WaitPID-Funktion auch

zurückkehrt, wenn einer der Kindprozesse gestoppt wurde.

Oder mit wContinued können wir durchsetzen, dass die Funktion WaitPID auch zurückkehrt,

wenn eines der Kinder fortgesetzt wird.

Der Status, den der Systemaufruf schreibt, wird in dem Speicherbereich gespeichert,

der als zweites Argument als Zeiger durchgereicht wird.

Der Status kann aber nicht sofort genutzt werden.

Stattdessen muss man erst mittels Makros prüfen, um was für einer Art von Status es sich handelt.

Möchte man zum Beispiel den Exit-Status eines Kinds prüfen, muss man erst nachschauen,

ob tatsächlich ein Exit-Status geschrieben wurde.

Dies funktioniert, indem man das Makro wIfExited nutzt.

Das Makro evaluiert zu falsch, falls der Kindprozess sich nicht normal beendet hat.

Wenn wir sichergestellt haben, dass es sich normal geendet hat, können wir den Status

mit dem Makro wExit-Status auslesen.

Ähnlich sieht es aus, um zu prüfen, ob einem Kindprozess ein Signal zugestellt wurde.

Erst müssen wir auf dem Status das Makro wIfSignaled aufrufen, um zu prüfen, ob dem Kindprozess