Scroll to navigation

signal(2) System Calls Manual signal(2)

NAAM

signal - ANSI C signaal afhandeling

BIBLIOTHEEK

Standard C bibliotheek (libc, -lc)

SAMENVATTING

#include <stdio.h>
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t afhandelaar);

BESCHRIJVING

WAARSCHUWING: Het gedrag van signal() varieert over UNIX systemen, en heeft ook historisch gevarieerd over de verschillende versies van Linux. Vermijd het gebruik; gebruik in zijn plaats signaction(2). Zie Overdraagbaarheid hieronder.

signal() stelt de dispositie van het signaal signum in op afhandelaar, hetgeen ofwel SIG_IGN is, of wel SIG_DFL of het adres van een door de programmeur gedefinieerde functie (een "signaal afhandelaar").

Zodra het signaal signum wordt afgeleverd bij een proces, dan zal een van de volgende dingen gebeuren:

*
Als de dispositie wordt gezet op SIG_IGN, dan wordt het signaal genegeerd.
*
Als de dispositie wordt gezet op SIG_DFL dan zal de standaard actie geassocieerd met het signaal (zie signal(7)) optreden.
*
Als de dispositie wordt gezet op een functie, dan wordt allereerst de dispositie gereset op SIG_DFL of het signaal wordt geblokkeerd (zie Overdraagbaarheid hieronder), en vervolgens wordt afhandelaar aangeroepen met argument signum. Als de aanroep van de afhandelaar er voor zorgt dat het signaal wordt geblokkeerd, dan wordt het signaal gedeblokkeerd bij terug keer van de afhandelaar.

De signalen SIGKILL en SIGSTOP kunnen niet worden gevangen of genegeerd.

EIND WAARDE

signal() geeft de vorige waarde van de signaal afhandelaar terug. Bij een fout, geeft het SIG_ERR terug en errno wordt gezet om de fout aan te duiden.

FOUTEN

signum is ongeldig.

VOLDOET AAN

POSIX.1-2001, POSIX.1-2008, C99.

OPMERKINGEN

De effecten van signal() in een multithreaded proces zijn niet gespecificeerd.

Volgens POSIX is het gedrag van een proces ongedefinieerd als het een SIGFPE, SIGILL of SIGSEGV negeert dat niet voortgebracht werd door de kill() of de raise() functies. Heel getal delen door nul heeft ongedefinieerd gevolg. Op sommige architecturen zal het een SIGFPE signaal veroorzaken. (Ook het delen van het meest negatieve hele getal door -1 kan een SIGFPE veroorzaken.) Negeren van dit signaal zou tot een eindeloze lus kunnen leiden.

Zie sigaction(2) voor details over wat er gebeurd als de dispositie SIGCHLD wordt gezet op SIG_IGN.

Zie signal-safety(7) voor een lijst van de async-signal-safe functies die veiligheid aangeroepen kunnen worden binnen een signaal afhandelaar.

Het gebruik van de sighandler_t is een GNU uitbreiding, voorhanden wanneer _GNU_SOURCE bepaald is; glibc definieert ook (afkomstig van BSB) sig_t als _BSD_SOURCE (glibc 2.19 en eerder) of _DEFAULT_SOURCE (glibc 2.19 en later) is bepaald. Zonder gebruik van zo een type is de declaratie van signal() iets moeilijker te lezen.s


void ( *signal(int signum, void (*afhandelaar)(int)) ) (int);

Overdraagbaarheid

Het enige overdraagbaar gebruik van signal() is door het zetten van de signaal dispositie op SIG_DFL of SIG_IGN. De semantiek bij het gebruik van signal() om een signaal afhandelaar over systemen tot stand te brengen (en POSIX.1 staat expliciet deze variatie toe); gebruik dit niet voor dit doel

POSIX.1 loste de overdraagbaarheid rotzooi op door het specificeren van sigaction(2), die voorziet in expliciete controle van de semantiek wanneer een signaal afhandelaar wordt aangeroepen; gebruik dit interface in plaats van signal().

In de originele UNIX systemen, als een afhandelaar die werd gevestigd gebruikmakend van signal() werd aangeroepen door het afleveren van een signaal, zou de dispositie van het signaal gereset worden tot SIG_DFL, en het systeem blokkeerde niet de aflevering van volgende instanties van het signaal. Dit is equivalent met het aanroepen van sigaction(2) met de volgende vlaggen:


sa.sa_flags = SA_RESETHAND | SA_NODEFER;

System V voorziet ook in deze semantiek van signal(). Dat was slecht omdat het signaal opnieuw zou kunnen worden afgeleverd voordat de afhandelaar de kans had gehad zichzelf te herstellen. Bovendien, zouden snelle leveringen van hetzelfde signaal kunnen resulteren in recursieve aanroepen van de afhandelaar.

BSD verbeterde deze situatie, echter veranderde helaas ook de semantiek van de bestaande signal() interface terwijl dit gebeurde. Op BSB, zodra een signaal afhandelaar wordt aangeroepen, wordt de signaal dispositie niet gereset, en volgende instanties van het signaal worden geblokkeerd om te worden afgeleverd terwijl de afhandelaar wordt uitgevoerd. Bovendien, worden bepaalde blokkerende systeem aanroepen automatisch geherstart als ze worden onderbroken door een signaal afhandelaar (zie signal(7)). De BSD semantiek is equivalent aan aanroepen van signaction(2) met de volgende vlaggen:


sa.sa_flags = SA_RESTART;

De situatie op Linux is als volgt:

•
De kernel signal() systeem aanroep voorziet in System V semantiek.
•
Standaard, in glibc 2 en later, roept de signal() omwikkel functie de kernel systeem aanroep niet aan. In plaats daarvan wordt sigaction(2) aangeroepen met de vlaggen die de BSD semantiek implementeren. Dit standaard gedrag wordt gemaakt zoals als een bruikbaar feature test macro werd gedefinieerd: _BSD_SOURCE op gllibc 2.19 en eerder of _DEFAULT_SOURCE in glibc 2.19 en later. (Standaard worden beide macros gedefinieerd; zie feature_test_macros(7) voor details.) Als zulk een feature test macro niet is gedefinieerd dan voorziet signal() in System V semantiek.

ZIE OOK

kill(1), alarm(2), kill(2), pause(2), sigaction(2), signalfd(2), sigpending(2), sigprocmask(2), sigsuspend(2), bsd_signal(3), killpg(3), raise(3), siginterrupt(3), sigqueue(3), sigsetops(3), sigvec(3), sysv_signal(3), signal(7)

VERTALING

De Nederlandse vertaling van deze handleiding is geschreven door Jos Boersema <joshb@xs4all.nl>, Mario Blättermann <mario.blaettermann@gmail.com> en Luc Castermans <luc.castermans@gmail.com>

Deze vertaling is vrije documentatie; lees de GNU General Public License Version 3 of later over de Copyright-voorwaarden. Er is geen AANSPRAKELIJKHEID.

Indien U fouten in de vertaling van deze handleiding zou vinden, stuur een e-mail naar debian-l10n-dutch@lists.debian.org.

5 februari 2023 Linux man-pagina's 6.03