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¶
Uwaga! To tłumaczenie może być nieaktualne!
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)
Powyższe tłumaczenie pochodzi z nieistniejącego już Projektu
Tłumaczenia Manuali i
może nie być aktualne. W razie
zauważenia różnic między powyższym opisem a
rzeczywistym zachowaniem opisywanego programu lub funkcji, prosimy o
zapoznanie się z oryginalną (angielską) wersją strony
podręcznika za pomocą polecenia:
- man --locale=C 2 signal
Prosimy o pomoc w aktualizacji stron man - więcej informacji można
znaleźć pod adresem
http://sourceforge.net/projects/manpages-pl/.
