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/.