Provided by: manpages-pl-dev_20051117-1_all bug

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)