signal

Autres langues

Langue: pl

Autres versions - même langue

Version: 2000-04-28 (openSuse - 09/10/07)

Autres sections - même nom

Section: 2 (Appels système)

NAZWA

signal - obs³uga sygna³ów ANSI C

SK£ADNIA

#include <signal.h>

typedef void (*sighandler_t)(int);

sighandler_t signal(int signum, sighandler_t handler);

OPIS

Funkcja systemowa signal() instaluje now± obs³ugê sygna³u dla sygna³u o numerze signum. Obs³uga sygna³u ustawiana jest na sighandler, który mo¿e byæ funkcj± podan± przez u¿ytkownika lub SIG_IGN albo SIG_DFL.

Po przys³aniu sygna³u o numerze signum dzieje siê, co nastêpuje. Je¶li obs³uga odpowiedniego sygna³u zosta³a ustawiona na SIG_IGN, to sygna³ jest ignorowany. Je¶li obs³uga zosta³a ustawiona na SIG_DFL, to podejmowana jest domy¶lna akcja skojarzona z sygna³em (patrz signal(7)). Ostatecznie, Je¶li jako obs³uga sygna³u zosta³a ustawiona function sighandler, to najpierw albo obs³uga sygna³u jest inicjowana na SIG_DFL albo odbywa siê zale¿ne od implementacji blokowanie sygna³u, a nastêpnie wywo³ywana jest funkcja sighandler z argumentem signum.

U¿ywanie funkcji obs³ugi sygna³u jest nazywane "przechwytywaniem sygna³u". Sygna³y SIGKILL i SIGSTOP nie mog± byæ ani przechwycone, ani zignorowane.

WARTO¦Æ ZWRACANA

Funkcja signal() zwraca poprzedni± warto¶æ obs³ugi sygna³u, lub SIG_ERR w przypadku b³êdu.

PRZENO¦NO¦Æ

Oryginalne uniksowe signal() zainicjalizowa³oby obs³ugê sygna³u na SIG_DFL i to samo robi System V (oraz j±dro Linuksa i libc4,5). Z drugiej strony, BSD nie inicjalizuje obs³ugi sygna³u, ale blokuje nowopojawiaj±ce siê egzemplarze tego sygna³u podczas wywo³ywania funkcji obs³ugi. Biblioteka glibc2 na¶laduje zachowanie BSD.

Je¶li w systemie opartym o libc5 zostanie w³±czone <bsd/signal.h> zamiast <signal.h>, to signal zostanie przedefiniowane jako __bsd_signal i bêdzie mia³o semantykê BSD. Nie jest to zalecane.

Je¶li w systemie opartym o glibc2 zdefiniowane zostanie makro testowania cechy, takie jak _XOPEN_SOURCE lub zostanie u¿yta osobna funkcja sysv_signal, otrzyma siê zachowanie klasyczne. Nie jest to zalecane.

Próba zmiany semantyki tej funkcji za pomoc± przedefiniowywania i w³±czania plików nag³ówkowych nie jest dobrym pomys³em. Lepiej w ogóle unikaæ funkcji signal i pos³ugiwaæ siê zamiast niej sigaction(2).

UWAGI

Zgodnie ze standardem POSIX, zachowanie procesu po zignorowaniu sygna³u SIGFPE, SIGILL lub SIGSEGV, który nie by³ wygenerowany przez funkcjê kill(2) ani raise(3), jest niezdefiniowane. Dzielenie przez zero liczby ca³kowitej nie ma okre¶lonego wyniku. Na niektórych architekturach generuje to sygna³ SIGFPE. (Równie¿ dzielenie najmniejszej liczby ujemnej przez -1 mo¿e spowodowaæ wygenerowanie SIGFPE.) Ignorowanie tego sygna³u mo¿e doprowadziæ do pêtli nieskoñczonej.

Zgodnie ze standardem POSIX (3.3.1.3) nie jest okre¶lone, co sie stanie gdy SIGCHLD zostanie ustawiony na SIG_IGN. W tym miejscu zachowanie BSD i SYSV ró¿ni siê, powoduj±c nie dzia³anie na Linuksie oprogramowania BSD, które ustawia akcjê dla SIGCHLD na SIG_IGN.

U¿ycie sighandler_t jest rozszerzeniem GNU. Ró¿ne wersje libc predefiniuj± ten typ; libc4 i libc5 definiuj± SignalHandler, glibc definiuje sig_t, a gdy zdefiniowane jest _GNU_SOURCE, równie¿ sighandler_t.

ZGODNE Z

ANSI C

ZOBACZ TAK¯E

kill(1), kill(2), killpg(2), pause(2), raise(3), sigaction(2), signal(7), sigsetops(3), sigvec(2), alarm(2)