sigaction(2) sigaction(2)
NAME
sigaction - Signalaktionen abrufen/ergänzen
SYNTAX
#include <signal.h>
int sigaction(int sig, const struct sigaction *act,
struct sigaction *oact);
BESCHREIBUNG
Mit der Funktion sigaction() kann der aufrufende Prozeß die Aktion,
die einem bestimmten Signal zugeordnet werden soll, prüfen und/oder
angeben. Das Argument sig gibt hierbei das Signal an. Die zulässigen
Werte sind in <signal.h> definiert.
Die Struktur sigaction, mit der eine auszuführende Aktion beschrieben
wird, ist in der Include-Datei <signal.h> definiert und enthält zumin-
dest die folgenden Komponenten:
Nur gültig, wenn mit "c89" generiert:
Komponententyp Komponentenname Beschreibung
__________________________________________________________________________
void(*) (int) sahandler SIGDFL, SIGIGN oder Zeiger auf eine
Funktion.
sigsett samask Zusätzliche Signalmenge, die während
der Ausführung der Signalbehandlungs-
funktion blockiert wird
int saflags Flags, die das Signalverhalten beein-
flussen
void(*) (int, siginfot *, void *)
sasigaction Signalbehandlungsfunktion
Nur gültig, wenn mit "cc" generiert:
void (*sahandler)();
sigsett samask;
int saflags;
Wenn das Argument act kein Nullzeiger ist, zeigt es auf eine Struktur,
die die Aktion angibt, die dem entsprechenden Signal zugeordnet werden
soll. Wenn das Argument oact kein Nullzeiger ist, wird die die Aktion,
die dem Signal zuvor zugeordnet war, an der Stelle gespeichert, auf
die das Argument oact zeigt. Wenn das Argument act ein Nullzeiger ist,
bleibt die Signalbehandlung unverändert. Auf diese Weise kann der Auf-
ruf zur Abfrage der aktuellen Behandlung eines bestimmten Signals ver-
wendet werden. Das Feld sahandler der Struktur sigaction gibt die
Aktion an, die dem entsprechenden Signal zugeordnet werden soll. Wenn
das Feld sahandler eine Signalbehandlungsfunktion angibt, gibt das
Feld samask eine Signalmenge an, die vor dem Aufrufen der Signalbe-
handlungsfunktion zur Signalmaske des Prozesses hinzugefügt wird. Die
Signale SIGKILL und SIGSTOP werden mit diesem Mechanismus nicht zur
Seite 1 Reliant UNIX 5.44 Gedruckt 11/98
sigaction(2) sigaction(2)
Signalmaske hinzugefügt. Diese Einschränkung wird durch das System
erzwungen, ohne daß ein Fehler angezeigt wird.
Das Feld saflags kann verwendet werden, um das Verhalten der angege-
benen Signale zu ändern.
Die folgenden in der Include-Datei <signal.h> definierten Flags können
in saflags gesetzt werden:
SANOCLDSTOP Kein SIGCHLD erzeugen, wenn Sohnprozesse angehalten
werden.
SAONSTACK Wenn dieses Flag gesetzt ist und ein alternativer
Signal-Stack mit sigaltstack() oder sigstack() dekla-
riert wurde, wird das Signal an den aufrufenden Prozeß
in diesem Stack ausgeliefert. Andernfalls wird das
Signal im aktuellen Stack ausgeliefert.
SARESETHAND Wenn dieses Flag gesetzt ist, wird die Voreinstellung
des Signals auf SIGDFL zurückgesetzt, und der Inhalt
des Flags SASIGINFO wird bei Eintritt in die Signal-
behandlungsroutine gelöscht. (Hinweis: SIGILL und
SIGTRAP können nach der Auslieferung nicht automatisch
zurückgesetzt werden. Diese Einschränkung wird vom
System stillschweigend erzwungen). Wenn das Flag nicht
gesetzt ist, wird die Voreinstellung des Signals bei
Eintritt in die Signalbehandlungsroutine nicht verän-
dert.
Wenn dieses Flag gesetzt ist, verhält sich sigaction()
ferner so, als wäre auch das Flag SANODEFER gesetzt.
SARESTART Dieses Flag beeinflußt das Verhalten von "unterbrech-
baren" Funktionen. (Wenn solche Funktionen fehlschla-
gen, wird errno auf EINTR gesetzt.) Ist SARESTART
gesetzt und wird eine dieser Funktionen durch dieses
Signal unterbrochen, so wird die Funktion neu gestar-
tet und schlägt, sofern nicht anders angegeben, nicht
mit dem Fehlercode EINTR fehl. Wenn das Flag nicht
gesetzt ist und eine unterbrechbare Funktion durch
dieses Signal unterbrochen wird, schlägt diese fehl,
wobei errno auf EINTR gesetzt wird.
SASIGINFO Wenn dieses Flag nicht gesetzt ist und das Signal
abgefangen wird, wird die Signalbehandlungsfunktion
wie folgt aufgerufen:
void func(int signo);
Seite 2 Reliant UNIX 5.44 Gedruckt 11/98
sigaction(2) sigaction(2)
Hierbei ist signo das einzige Argument für die Signal-
behandlungsfunktion. In diesem Fall muß die Komponente
sahandler zur Beschreibung der Signalbehandlungsfunk-
tion verwendet werden, und die Anwendung darf die Kom-
ponente sasigaction nicht ändern.
Nur gültig, wenn im XPG4-Modus generiert (mit "c89"):
Wenn SASIGINFO gesetzt ist und das Signal abgefangen
wird, wird die Signalbehandlungsfunktion wie folgt
aufgerufen:
void func(int signo, siginfot *info, void *context);
Hierbei werden zwei weitere Argumente an die Signalbe-
handlungsfunktion übergeben. Wenn das zweite Argument
kein Nullzeiger ist, zeigt es auf ein Objekt des Typs
siginfot, das die Ursache für die Erzeugung des Sig-
nals erläutert. Das dritte Argument kann an einen Zei-
ger auf ein Objekt des Typs ucontextt übergeben wer-
den, um auf den Kontext des empfangenden Prozesses zu
verweisen, der bei Auslieferung des Signals unterbro-
chen wurde. In diesem Fall muß die Komponente
sasigaction zur Beschreibung der Signalbehandlungs-
funktion verwendet werden, und die Anwendung darf die
Komponente sahandler nicht ändern.
Nur gültig, wenn mit "cc" generiert:
Wenn die Option gesetzt ist und das Signal behandelt
wird, werden blockierte Signale vom Typ sig zuverläs-
sig für den aufrufenden Prozeß in die Warteschlange
aufgenommen und zwei zusätzliche Argumente an die
Funktion übergeben, die das Signal bearbeitet. Wenn
das zweite Argument nicht gleich NULL ist, zeigt es
auf eine Struktur vom Typ siginfot, welche den Grund
für das Signal enthält [siehe siginfo(5)]; das dritte
Argument zeigt auf eine Struktur vom Typ ucontextt,
welche den Kontext des empfangenden Prozesses zur Zeit
des Signalempfangs enthält [siehe ucontext(5)].
Im folgenden wieder für beide Compiler gültig:
Die Komponente sisigno enthält die vom System
erzeugte Signalnummer.
Die Komponente sierrno kann je nach Implementierung
zusätzliche Fehlerinformationen enthalten. Bei einem
Wert ungleich Null enthält sie eine Fehlernummer, die
die Bedingung für die Erzeugung des Signals angibt.
Seite 3 Reliant UNIX 5.44 Gedruckt 11/98
sigaction(2) sigaction(2)
Die Komponente sicode enthält einen Code, der die
Ursache des Signals angibt. Ist der Wert von sicode
kleiner als oder gleich 0, dann wurde das Signal von
einem Prozeß erzeugt und sipid beziehungsweise siuid
geben die Prozeß-ID und die reale Benutzer-ID des Sen-
ders an. Die Werte von sipid und siuid sind anson-
sten ohne Bedeutung.
SANOCLDWAIT Wenn dieses Flag gesetzt und sig gleich SIGCHLD ist,
werden Sohnprozesse des aufrufenden Prozesses bei
ihrem Beenden nicht in Zombie-Prozesse umgewandelt.
Wenn der aufrufende Prozeß nachfolgend auf seine Sohn-
prozesse wartet, und der Prozeß keine in Zombie-Pro-
zesse umgewandelte Sohnprozesse hat, auf die nicht
gewartet wird, blockiert er so lange, bis alle seine
Sohnprozesse beendet sind, und wait(), wait3(),
waitid() sowie waitpid() schlagen fehl, wobei errno
auf ECHILD gesetzt wird. Wenn dieses Flag dagegen
nicht gesetzt ist, werden Sohnprozesse bei ihrem Been-
den in Zombie-Prozesse umgewandelt, sofern SIGCHLD
nicht auf SIGIGN gesetzt ist.
SANODEFER Wenn dieses Flag gesetzt ist und sig abgefangen wird,
wird sig bei Eintritt in die Signalbehandlungsroutine
nicht zur Signalmaske des Prozesses hinzugefügt, es
sei denn, es ist in samask enthalten. Ist das Flag
nicht gesetzt, wird sig bei Eintritt in die Signalbe-
handlungsroutine stets zur Signalmaske des Prozesses
hinzugefügt.
Handelt es sich bei sig um das Signal SIGCHLD und ist das Flag
SANOCLDSTOP in saflags nicht gesetzt, wird - vorausgesetzt die
Implementierung unterstützt das Signal SIGCHLD - ein SIGCHLD-Signal
für den aufrufenden Prozeß erzeugt, sobald einer seiner Sohnprozesse
angehalten wird. Handelt es sich bei sig um das Signal SIGCHLD und ist
das Flag SANOCLDSTOP in saflags gesetzt, erzeugt die Implementierung
kein SIGCHLD-Signal auf diese Weise.
Wird ein Signal von einer durch sigaction() installierten Signalbe-
handlungsfunktion abgefangen, wird eine neue Signalmaske berechnet und
für die Ausführungsdauer dieser Funktion (oder so lange, bis die Funk-
tion sigprocmask() oder sigsuspend() aufgerufen wird) installiert.
Diese Maske wird aus dem Zusammenschluß der aktuellen Signalmaske und
dem Wert von samask für das ausgelieferte Signal (sofern nicht
SANODEFER oder SARESETHAND gesetzt ist) und anschließendem Einfügen
des ausgelieferten Signals gebildet. Wenn die Signalbehandlungsroutine
des Benutzers normal angehalten wird, wird die ursprüngliche Signal-
maske wiederhergestellt.
Seite 4 Reliant UNIX 5.44 Gedruckt 11/98
sigaction(2) sigaction(2)
Nachdem eine Aktion für ein bestimmtes Signal installiert wurde, gilt
diese so lange, bis eine andere Aktion explizit (durch einen weiteren
Aufruf von sigaction()) angefordert, die Signalbehandlungsroutine
durch das Flag SARESETHAND zurückgesetzt oder eine der exec-Funk-
tionen aufgerufen wird.
Wurde die vorherige Aktion für sig durch die Funktion signal(),
erstellt, sind die Werte der Felder, die in der Struktur zurückgegeben
werden, auf die oact zeigt, nicht definiert. Insbesondere
oact->sahandler muß nicht zwangsläufig der Wert sein, der auch an
signal() übergeben wird. Wenn allerdings ein Zeiger auf dieselbe
Struktur oder eine Kopie dieser Struktur über das Argument act an
einen nachfolgenden Aufruf von sigaction() übergeben wird, ist die
Behandlung des Signals so, als würde der ursprüngliche Aufruf von
signal() wiederholt.
Wenn sigaction() fehlschlägt, wird keine neue Signalbehandlungsroutine
installiert.
Es ist nicht definiert, ob der Versuch, eine Aktion für ein Signal,
das weder abgefangen noch ignoriert werden kann, auf SIGDFL zu set-
zen, ignoriert wird oder die Auslieferung eines Fehlers zur Folge hat,
bei dem errno auf EINVAL gesetzt wird.
Ein Signal gilt als für einen Prozeß erzeugt (generated), d. h. an ihn
gesendet, wenn das Ereignis, welches das Signal verursacht, zum ersten
Mal auftritt. Zu solchen Ereignissen zählen beispielsweise das Auftre-
ten von Gerätefehlern, das Ablaufen eines Zeitgebers und Aktivitäten
am Terminal sowie ein Aufruf von kill(). Unter Umständen kann dasselbe
Ereignis Signale für mehrere Prozesse erzeugen.
Als Reaktion auf jedes vom System definierte Signal muß jeder Prozeß
eine Aktion ausführen (siehe Signalaktionen). Ein Signal gilt als an
einen Prozeß ausgeliefert (delivered), sobald die für diesen Prozeß
und dieses Signal vorgesehene Aktion ausgeführt wurde.
Von dem Zeitpunkt seiner Erzeugung bis zu seiner Auslieferung wird ein
Signal als anstehend (pending) bezeichnet. Normalerweise kann dieser
Zustand von einer Anwendung nicht erkannt werden. Ein Signal kann
jedoch von seiner Auslieferung an einen Prozeß blockiert (blocked)
sein. Wenn für ein blockiertes Signal eine andere Aktion als das Igno-
rieren des Signals vorgesehen ist, und wenn dieses Signal für den Pro-
zeß erzeugt wird, so bleibt das Signal anstehend, bis es entweder
freigegeben wird, oder bis die zugeordnete Aktion auf Ignorieren des
Signals gesetzt wird. Ist die einem blockierten Signal zugeordnete
Aktion so gesetzt, daß sie das Signal ignoriert, und wird dieses Sig-
nal für den Prozeß erzeugt, ist nicht definiert, ob das Signal direkt
nach der Erzeugung gelöscht wird oder ob es weiterhin als anstehend
gewertet wird.
Seite 5 Reliant UNIX 5.44 Gedruckt 11/98
sigaction(2) sigaction(2)
Jeder Prozeß hat eine "Signalmaske", die die Signalmenge definiert,
deren Auslieferung an den Prozeß zur Zeit blockiert ist. Die Signal-
maske für einen Prozeß wird durch die des Vaterprozesses initiali-
siert. Die Funktionen sigaction(), sigprocmask() und sigsuspend()
steuern das Manipulieren der Signalmaske.
Welche Aktion als Antwort auf ein Signal auszuführen ist, wird erst
bei der Auslieferung des Signals festgelegt, so daß noch eventuelle
Änderungen nach der Erzeugung des Signals möglich sind. Diese Festle-
gung der Aktion ist dabei unabhängig von dem Signalauslöser. Wird ein
nachfolgendes Auftreten eines anstehenden Signals erzeugt, hängt es
von der Implementierung ab, ob das Signal mehr als ein Mal ausgelie-
fert wird. Die Reihenfolge, in der mehrere anstehende Signale an einen
Prozeß ausgeliefert werden, ist nicht definiert.
Wenn ein Stoppsignal (SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) für einen
Prozeß erzeugt wird, werden alle für diesen Prozeß anstehenden Signale
SIGCONT gelöscht. Wenn andererseits SIGCONT für einen Prozeß erzeugt
wird, werden alle für diesen Prozeß anstehenden Stoppsignale gelöscht.
Wenn SIGCONT für einen angehaltenen Prozeß erzeugt wird, wird der Pro-
zeß fortgesetzt, auch wenn das Signal SIGCONT blockiert oder ignoriert
wird. Wird SIGCONT blockiert, aber nicht ignoriert, bleibt es so lange
anstehend, bis es entweder wieder freigegeben oder ein Stoppsignal für
den Prozeß erzeugt wird.
Signalaktionen
Es gibt drei Aktionstypen, die einem Signal zugeordnet werden können:
SIGDFL, SIGIGN oder ein Zeiger auf eine Funktion. Vor dem Eintritt
in die Routine main() (siehe die exec-Funktionen) werden zunächst alle
Signale auf SIGDFL oder SIGIGN gesetzt. Die durch diese Werte vorge-
gebenen Aktionen sind:
SIGDFL - signalspezifische Standardaktion
- Die Standardaktionen für die in diesem Dokument definierten
Signale sind in <signal.h> angegeben.
- Gibt die Standardfunktion an, daß der Prozeß angehalten werden
soll, wird die Ausführung dieses Prozesses vorübergehend
zurückgestellt. Wenn ein Prozeß angehalten wird, wird ein Sig-
nal SIGCHLD für seinen Vaterprozeß erzeugt, sofern der Vater-
prozeß nicht das Flag SANOCLDSTOP gesetzt hat. Während ein
Prozeß angehalten ist, werden alle weiteren an den Prozeß
gesendeten Signale so lange nicht ausgeliefert, bis der Prozeß
fortgesetzt wird. Ausgenommen hiervon ist das Signal SIGKILL,
das den empfangenden Prozeß immer beendet. Ein Prozeß, der zu
einer verwaisten Prozeßmenge gehört, wird bei Empfang der Sig-
nale SIGTSTP, SIGTTIN oder SIGTTOU nicht angehalten. Wenn die
Auslieferung eines dieser Signale einen solchen Prozeß anhalten
würde, wird dieses Signal gelöscht.
Seite 6 Reliant UNIX 5.44 Gedruckt 11/98
sigaction(2) sigaction(2)
- Wird eine Signalaktion für ein anstehendes Signal, dessen Stan-
dardaktion das Ignorieren des Signals (zum Beispiel SIGCHLD)
ist, auf SIGDFL gesetzt, so wird das anstehende Signal
gelöscht, und zwar unabhängig davon, ob es blockiert wird oder
nicht.
SIGIGN - Signal ignorieren
- Auslieferung des Signals hat keine Auswirkungen auf den Prozeß.
Das Verhalten eines Prozesses ist unbestimmt, wenn ein Signal
SIGFPE, SIGILL oder SIGSEGV ignoriert wurde, das nicht durch
kill() oder raise() erzeugt worden ist.
- Das System läßt nicht zu, daß die Aktion für die Signale
SIGKILL oder SIGSTOP auf SIGIGN gesetzt werden.
- Wird eine Signalaktion für ein anstehendes Signal auf SIGIGN
gesetzt, so wird das anstehende Signal gelöscht, und zwar unab-
hängig davon, ob es blockiert wird oder nicht.
- Setzt ein Prozeß die Aktion für das Signal SIGCHLD auf SIGIGN,
ist das Verhalten außer bei folgender Situation unbestimmt:
Wenn die Aktion für das Signal SIGCHLD auf SIGIGN gesetzt ist,
werden Sohnprozesse des aufrufenden Prozesses nicht in Zombie-
Prozesse umgewandelt, wenn sie enden. Wenn der aufrufende Pro-
zeß nachfolgend auf seine Sohnprozesse wartet, und der Prozeß
keine in Zombie-Prozesse umgewandelte Sohnprozesse hat, auf die
nicht gewartet wird, blockiert er so lange, bis alle seine
Sohnprozesse beendet sind und wait(), wait3(), waitid() sowie
waitpid() schlagen fehl, wobei errno auf ECHILD gesetzt wird.
Zeiger auf eine Funktion - Signal abfangen
- Bei Auslieferung des Signals muß der empfangende Prozeß die
Funktion, die die Signale abfängt, an der angegebenen Adresses
ausführen. Anschließend nimmt der Prozeß die Ausführung an der
Stelle wieder auf, an der er unterbrochen wurde.
- Wenn SASIGINFO nicht gesetzt ist, wird die Signalbehandlungs-
funktion wie folgt aufgerufen:
void func(int signo);
Hierbei ist func die angegebene Signalbehandlungsfunktion und
signo ist die Signalnummer des ausgelieferten Signals.
- Wenn SASIGINFO gesetzt ist, wird die Signalbehandlungsfunktion
wie folgt aufgerufen:
void func(int signo, siginfot *siginfo, void *ucontextptr);
Seite 7 Reliant UNIX 5.44 Gedruckt 11/98
sigaction(2) sigaction(2)
Hierbei ist func die angegebene Signalbehandlungsfunktion,
signo ist die Signalnummer des ausgelieferten Signals, siginfo
zeigt auf ein Objekt des Typs siginfot, das dem ausgelieferten
Signal zugeordnet ist und ucontextptr zeigt auf ein ucontextt.
- Das Verhalten eines Prozesses ist nicht definiert, wenn er nor-
mal von einer Signalbehandlungsfunktion für ein Signal SIGBUS,
SIGFPE, SIGILL oder SIGSEGV, das nicht durch kill() oder
raise() erzeugt worden ist, zurückkehrt.
- Das System läßt nicht zu, daß ein Prozeß die Signale SIGKILL
und SIGSTOP abfängt.
- Wenn ein Prozeß eine Signalbehandlungsfunktion für das Signal
SIGCHLD erstellt und einen beendeten Sohnprozeß enthält, auf
den nicht gewartet wurde, ist nicht definiert, ob ein SIGCHLD-
Signal zur Angabe des Sohnprozesses erzeugt wird.
- Wenn Signalbehandlungsfunktionen asynchron zur Prozeßausführung
aufgerufen werden, ist das Verhalten einiger der definierten
Funktionen unbestimmt, wenn sie von einer Signalbehandlungs-
funktion aufgerufen werden.
Die folgende Tabelle definiert eine Gruppe von Funktionen, die
entweder wiedereintrittsfähig sind oder nicht durch Signale
unterbrochen werden können. Daher können Anwendungen diese
Funktionen ohne Einschränkungen von Signalbehandlungsfunktionen
aus aufrufen.
access() fstat() read() sysconf()
alarm() getegid() rename() tcdrain()
cfgetispeed() geteuid() rmdir() tcflow()
cfgetospeed() getgid() setgid() tcflush()
cfsetispeed() getgroups() setpgid() tcgetattr()
cfsetospeed() getpgrp() setsid() tcgetpgrp()
chdir() getpid() setuid() tcsendbreak()
chmod() getppid() sigaction() tcsetattr()
chown() getuid() sigaddset() tcsetpgrp()
close() kill() sigdelset() time()
creat() link() sigemptyset() times()
dup2() lseek() sigfillset() umask()
dup() mkdir() sigismember() uname()
execle() mkfifo() signal() unlink()
execve() open() sigpending() utime()
exit() pathconf() sigprocmask() wait()
fcntl() pause() sigsuspend() waitpid()
fork() pipe() sleep() write()
fpathconf() raise() stat()
Seite 8 Reliant UNIX 5.44 Gedruckt 11/98
sigaction(2) sigaction(2)
Alle nicht in dieser Tabelle aufgelisteten Funktionen sind im
Zusammenhang mit Signalen als unsicher zu betrachten. Wenn Sig-
nale vorliegen, verhalten sich alle Funktionen entsprechend der
Definition, wenn sie von einer Signalbehandlungsfunktion aufge-
rufen oder unterbrochen werden. Nur wenn ein Signal eine unsi-
chere Funktion unterbricht und die Signalbehandlungsfunktion
eine unsichere Funktion aufruft, ist das Verhalten nicht defi-
niert.
Auswirkungen von Signalen auf andere Funktionen
Signale wirken sich auf das Verhalten bestimmter, im vorliegenden
Dokument definierter Funktionen aus, wenn sie an einen Prozeß ausge-
liefert werden, während dieser eine solche Funktion ausführt. Handelt
es sich um ein Signal, das den Prozeß beenden soll, wird der Prozeß
beendet und die Funktion kehrt nicht zurück. Handelt es sich um ein
Signal, das den Prozeß anhalten soll, wird der Prozeß angehalten, bis
er fortgesetzt oder beendet wird. Die Generierung eines Signals
SIGCONT für den Prozeß führt dazu, daß der Prozeß fortgesetzt wird,
und die urprüngliche Funktion an der Stelle wieder aufgenommen wird,
an der der Prozeß angehalten wurde. Handelt es sich um ein Signal, das
eine Signalbehandlungsfunktion aufruft, wird die entsprechende Funk-
tion aufgerufen; in diesem Fall wird die ursprüngliche Funktion als
durch das Signal unterbrochen bezeichnet. Führt die Signalbehandlungs-
funktion eine Anweisung return aus, ist das Verhalten der unterbroche-
nen Funktion wie für die jeweilige Funktion definiert. Signale, die
ignoriert werden, haben keine Auswirkung auf das Verhalten von Funk-
tionen. Signale, die blockiert werden, wirken sich erst auf das Ver-
halten der Funktion aus, wenn das Signal freigegeben und ausgeliefert
wird.
RÜCKGABEWERT
Nach erfolgreicher Ausführung gibt sigaction() den Wert 0 zurück.
Andernfalls wird -1 zurückgegeben, errno wird zur Anzeige des Fehlers
gesetzt, und es wird keine neue Signalbehandlungsfunktion installiert.
FEHLER
Die folgenden Beschreibungen der Fehlercodes sind funktionsspezifisch.
Eine allgemeingültige Beschreibung finden Sie in introprm2(2) bzw. in
errno(5).
Die Funktion sigaction() schlägt bei folgender Bedingung fehl:
EINVAL Das Argument sig ist keine gültige Signalnummer oder es
wurde versucht, ein Signal abzufangen/zu ignorieren, das
nicht abgefangen/ignoriert werden kann.
Die Funktion sigaction() kann bei folgender Bedingung fehlschlagen:
EINVAL Es wurde versucht, die Aktion für ein Signal, das nicht
abgefangen und/oder nicht ignoriert werden kann, auf SIGDFL
zu setzen.
Seite 9 Reliant UNIX 5.44 Gedruckt 11/98
sigaction(2) sigaction(2)
ANWENDUNGSZWECK
Die Funktion sigaction() löst die Schnittstelle signal() ab und sollte
bevorzugt verwendet werden. Insbesondere sollten sigaction() und
signal() nicht im selben Prozeß zur Steuerung desselben Signals ver-
wendet werden. Das Verhalten von wiedereintrittsfähigen Funktionen,
wie in der Beschreibung definiert, entspricht den Angaben im vorlie-
genden Dokument, und zwar unabhängig davon, ob sie von einer Signalbe-
handlungsfunktion aufgerufen werden. Dies und nichts anderes ist mit
der obigen Aussage, daß wiedereintrittsfähige Funktionen in Signalbe-
handlungsfunktionen ohne Einschränkung verwendet werden können,
gemeint. In Anwendungen müssen also auch weiterhin alle Auswirkungen
solcher Funktionen auf beispielsweise Datenstrukturen, Dateien und den
Prozeßstatus berücksichtigt werden. Insbesondere müssen Anwendungsent-
wickler die Einschränkungen hinsichtlich Interaktionen bei der Unter-
brechung von sleep() sowie Interaktionen zwischen mehreren Handles für
eine Dateibeschreibung berücksichtigen. Die Tatsache, daß eine
bestimmte Funktion als wiedereintrittsfähig aufgelistet ist, muß nicht
bedeuten, daß der Aufruf dieser Funktion über eine Signalbehandlungs-
routine empfohlen wird.
Zur Vermeidung von Fehlern, die bei einer Unterbrechung von Aufrufen
einer nicht-wiedereintrittsfähiger Funktionen auftreten können, soll-
ten Aufrufe solcher Funktionen seitens der Anwendung geschützt werden,
indem entweder die entsprechenden Signale blockiert werden, oder pro-
grammspezifische Semaphoren eingesetzt werden. Im vorliegenden Doku-
ment werden keine allgemeinen Probleme hinsichtlich der Synchronisie-
rung beim Zugriff auf gemeinsam verwendete Datenstrukturen behandelt.
Achten Sie hier besonders darauf, daß sogar "sichere" Funktionen die
globale Variable errno ändern können; möglicherweise will die Signal-
behandlungsfunktion ihren Wert sichern und wiederherstellen. Dasselbe
Prinzip gilt natürlich auch für die Wiedereintrittsfähigkeit von
Anwendungsroutinen und den asynchronen Datenzugriff. longjmp() und
siglongjmp() sind nicht in der Liste der wiedereintrittsfähigen Funk-
tionen enthalten, da der nach longjmp() und siglongjmp() ausgeführte
Code unsichere Funktionen aufrufen kann, was dieselben Probleme verur-
sacht wie der direkte Aufruf dieser Funktionen über die Signalbehand-
lungsroutine. Für Anwendungen, die longjmp() und siglongjmp() von Sig-
nalbehandlungsroutinen aus verwenden, ist ein strikter Schutz erfor-
derlich, um die Portierbarkeit dieser Anwendungen zu gewährleisten.
Viele der anderen Funktionen, die nicht in der Liste enthalten sind,
werden normalerweise über die Funktionen malloc() oder free() oder die
Standard-Ein-/Ausgabebibliothek implementiert, die Datenstrukturen
normalerweise nicht wiedereintrittsfähig verwenden. Da die Kombination
verschiedener Funktionen, die eine gemeinsame Datenstruktur verwenden,
Probleme in bezug auf die Wiedereintrittsfähigkeit verursachen können,
ist das Verhalten nicht definiert, wenn eine unsichere Funktion in
einer Signalbehandlungsroutine aufgerufen wird, die eine unsichere
Funktion unterbricht.
Seite 10 Reliant UNIX 5.44 Gedruckt 11/98
sigaction(2) sigaction(2)
Tritt das Signal nicht aufgrund eines Aufrufs von abort(), kill() oder
raise() auf, ist das Verhalten unbestimmt, wenn die Signalbehandlungs-
routine eine Funktion aus der Standardbibliothek aufruft, die nicht in
obenstehender Liste enthalten ist, oder auf ein statisch gespeichertes
Objekt verweist, ohne daß einer statischen Speicher-Variablen vom Typ
volatile sigatomict ein Wert zugeordnet wurde. Ferner ist der Wert
von errno unbestimmt, wenn ein solcher Aufruf fehlschlägt.
Normalerweise wird das Signal in dem Stack ausgeführt, der vor Auslie-
ferung des Signals aktiv war. Ein alternativer Stack kann angegeben
werden, um eine Untermenge der abgefangenen Signale zu empfangen.
Nach Beendigung der Signalbehandlungsroutine nimmt der empfangende
Prozeß die Ausführung an der Stelle wieder auf, an der er unterbrochen
wurde, sofern die Signalbehandlungsroutine nichts anderes vorsieht.
Wenn longjmp() oder longjmp() zum Verlassen der Signalbehandlungsrou-
tine verwendet wird, muß die Signalmaske explizit vom Prozeß wieder-
hergestellt werden.
POSIX.4-1993 definiert das dritte Argument der Signalbehandlungsfunk-
tion, wenn SASIGINFO auf void * anstatt auf ucontextt * gesetzt
wird, jedoch ohne daß eine Typenüberprüfung erforderlich ist. Neue
Anwendungen sollten das dritte Argument der Signalbehandlungsfunktion
explizit auf uncontextt * setzen.
Die optionale BSD-Signalbehandlungsfunktion mit vier Argumenten wird
von vorliegender Spezifikation nicht unterstützt. Für BSD würde die
Deklaration wie folgt lauten:
void handler(int sig, int code, struct sigcontext *scp,
char *addr);
Hierbei ist sig die Signalnummer, code sind zusätzliche Informationen
zu bestimmten Signalen, scp ist ein Zeiger auf eine Signalkontext-
struktur und addr sind zusätzliche Adreßinformationen. Nahezu identi-
sche Informationen stehen in den Objekten zur Verfügung, auf die das
zweite Argument der Signalbehandlungsroutine zeigt, die angegeben
wird, wenn SASIGINFO gesetzt ist.
SIEHE AUCH
kill(1), exit(2), introprm2(2), kill(2), pause(2), sigaltstack(2),
signal(2), sigprocmask(2), sigsend(2), sigsuspend(2), wait(2),
waitid(2), waitpid(2), wait3(3), raise(3C), setjmp(3C-ucb),
sigsetops(3C), siginfo(5), signal(5), ucontext(5).
Handbuch "C-Compiler", Kapitel "Das cc/c89-Kommando".
Seite 11 Reliant UNIX 5.44 Gedruckt 11/98