/usr/share/doc/glibc-doc/html/libc_24.html is in glibc-doc 2.15-0ubuntu10.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html401/loose.dtd">
<html>
<!-- This file documents the GNU C library.
This is Edition 0.13, last updated 2011-07-19,
of The GNU C Library Reference Manual, for version
2.14 (Ubuntu EGLIBC 2.15-0ubuntu10) .
Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002,
2003, 2007, 2008, 2010, 2011 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "Free Software Needs Free Documentation"
and "GNU Lesser General Public License", the Front-Cover texts being
"A GNU Manual", and with the Back-Cover Texts as in (a) below. A
copy of the license is included in the section entitled "GNU Free
Documentation License".
(a) The FSF's Back-Cover Text is: "You have the freedom to
copy and modify this GNU manual. Buying copies from the FSF
supports it in developing GNU and promoting software freedom."
-->
<!-- Created on April 20, 2012 by texi2html 1.82
texi2html was written by:
Lionel Cons <Lionel.Cons@cern.ch> (original author)
Karl Berry <karl@freefriends.org>
Olaf Bachmann <obachman@mathematik.uni-kl.de>
and many others.
Maintained by: Many creative people.
Send bugs and suggestions to <texi2html-bug@nongnu.org>
-->
<head>
<title>The GNU C Library: 24. Signal Handling</title>
<meta name="description" content="The GNU C Library: 24. Signal Handling">
<meta name="keywords" content="The GNU C Library: 24. Signal Handling">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="texi2html 1.82">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.smallquotation {font-size: smaller}
pre.display {font-family: serif}
pre.format {font-family: serif}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: serif; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: serif; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.roman {font-family:serif; font-weight:normal;}
span.sansserif {font-family:sans-serif; font-weight:normal;}
ul.toc {list-style: none}
-->
</style>
</head>
<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<a name="Signal-Handling"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="libc_23.html#System-V-contexts" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Concepts-of-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc_23.html#Non_002dLocal-Exits" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Signal-Handling-1"></a>
<h1 class="chapter">24. Signal Handling</h1>
<a name="index-signal-1"></a>
<p>A <em>signal</em> is a software interrupt delivered to a process. The
operating system uses signals to report exceptional situations to an
executing program. Some signals report errors such as references to
invalid memory addresses; others report asynchronous events, such as
disconnection of a phone line.
</p>
<p>The GNU C library defines a variety of signal types, each for a
particular kind of event. Some kinds of events make it inadvisable or
impossible for the program to proceed as usual, and the corresponding
signals normally abort the program. Other kinds of signals that report
harmless events are ignored by default.
</p>
<p>If you anticipate an event that causes signals, you can define a handler
function and tell the operating system to run it when that particular
type of signal arrives.
</p>
<p>Finally, one process can send a signal to another process; this allows a
parent process to abort a child, or two related processes to communicate
and synchronize.
</p>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#Concepts-of-Signals">24.1 Basic Concepts of Signals</a></td><td> </td><td align="left" valign="top"> Introduction to the signal facilities.
</td></tr>
<tr><td align="left" valign="top"><a href="#Standard-Signals">24.2 Standard Signals</a></td><td> </td><td align="left" valign="top"> Particular kinds of signals with
standard names and meanings.
</td></tr>
<tr><td align="left" valign="top"><a href="#Signal-Actions">24.3 Specifying Signal Actions</a></td><td> </td><td align="left" valign="top"> Specifying what happens when a
particular signal is delivered.
</td></tr>
<tr><td align="left" valign="top"><a href="#Defining-Handlers">24.4 Defining Signal Handlers</a></td><td> </td><td align="left" valign="top"> How to write a signal handler function.
</td></tr>
<tr><td align="left" valign="top"><a href="#Interrupted-Primitives">24.5 Primitives Interrupted by Signals</a></td><td> </td><td align="left" valign="top"> Signal handlers affect use of <code>open</code>,
<code>read</code>, <code>write</code> and other functions.
</td></tr>
<tr><td align="left" valign="top"><a href="#Generating-Signals">24.6 Generating Signals</a></td><td> </td><td align="left" valign="top"> How to send a signal to a process.
</td></tr>
<tr><td align="left" valign="top"><a href="#Blocking-Signals">24.7 Blocking Signals</a></td><td> </td><td align="left" valign="top"> Making the system hold signals temporarily.
</td></tr>
<tr><td align="left" valign="top"><a href="#Waiting-for-a-Signal">24.8 Waiting for a Signal</a></td><td> </td><td align="left" valign="top"> Suspending your program until a signal
arrives.
</td></tr>
<tr><td align="left" valign="top"><a href="#Signal-Stack">24.9 Using a Separate Signal Stack</a></td><td> </td><td align="left" valign="top"></td></tr>
<tr><td align="left" valign="top"><a href="#BSD-Signal-Handling">24.10 BSD Signal Handling</a></td><td> </td><td align="left" valign="top"> Additional functions for backward
compatibility with BSD.
</td></tr>
</table>
<hr size="6">
<a name="Concepts-of-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Signal-Handling" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Kinds-of-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Basic-Concepts-of-Signals"></a>
<h2 class="section">24.1 Basic Concepts of Signals</h2>
<p>This section explains basic concepts of how signals are generated, what
happens after a signal is delivered, and how programs can handle
signals.
</p>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#Kinds-of-Signals">24.1.1 Some Kinds of Signals</a></td><td> </td><td align="left" valign="top"> Some examples of what can cause a signal.
</td></tr>
<tr><td align="left" valign="top"><a href="#Signal-Generation">24.1.2 Concepts of Signal Generation</a></td><td> </td><td align="left" valign="top"> Concepts of why and how signals occur.
</td></tr>
<tr><td align="left" valign="top"><a href="#Delivery-of-Signal">24.1.3 How Signals Are Delivered</a></td><td> </td><td align="left" valign="top"> Concepts of what a signal does to the
process.
</td></tr>
</table>
<hr size="6">
<a name="Kinds-of-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Concepts-of-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Generation" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Concepts-of-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Some-Kinds-of-Signals"></a>
<h3 class="subsection">24.1.1 Some Kinds of Signals</h3>
<p>A signal reports the occurrence of an exceptional event. These are some
of the events that can cause (or <em>generate</em>, or <em>raise</em>) a
signal:
</p>
<ul>
<li>
A program error such as dividing by zero or issuing an address outside
the valid range.
</li><li>
A user request to interrupt or terminate the program. Most environments
are set up to let a user suspend the program by typing <kbd>C-z</kbd>, or
terminate it with <kbd>C-c</kbd>. Whatever key sequence is used, the
operating system sends the proper signal to interrupt the process.
</li><li>
The termination of a child process.
</li><li>
Expiration of a timer or alarm.
</li><li>
A call to <code>kill</code> or <code>raise</code> by the same process.
</li><li>
A call to <code>kill</code> from another process. Signals are a limited but
useful form of interprocess communication.
</li><li>
An attempt to perform an I/O operation that cannot be done. Examples
are reading from a pipe that has no writer (see section <a href="libc_15.html#Pipes-and-FIFOs">Pipes and FIFOs</a>),
and reading or writing to a terminal in certain situations (see section <a href="libc_27.html#Job-Control">Job Control</a>).
</li></ul>
<p>Each of these kinds of events (excepting explicit calls to <code>kill</code>
and <code>raise</code>) generates its own particular kind of signal. The
various kinds of signals are listed and described in detail in
<a href="#Standard-Signals">Standard Signals</a>.
</p>
<hr size="6">
<a name="Signal-Generation"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Kinds-of-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Delivery-of-Signal" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Concepts-of-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Concepts-of-Signal-Generation"></a>
<h3 class="subsection">24.1.2 Concepts of Signal Generation</h3>
<a name="index-generation-of-signals"></a>
<p>In general, the events that generate signals fall into three major
categories: errors, external events, and explicit requests.
</p>
<p>An error means that a program has done something invalid and cannot
continue execution. But not all kinds of errors generate signals—in
fact, most do not. For example, opening a nonexistent file is an error,
but it does not raise a signal; instead, <code>open</code> returns <code>-1</code>.
In general, errors that are necessarily associated with certain library
functions are reported by returning a value that indicates an error.
The errors which raise signals are those which can happen anywhere in
the program, not just in library calls. These include division by zero
and invalid memory addresses.
</p>
<p>An external event generally has to do with I/O or other processes.
These include the arrival of input, the expiration of a timer, and the
termination of a child process.
</p>
<p>An explicit request means the use of a library function such as
<code>kill</code> whose purpose is specifically to generate a signal.
</p>
<p>Signals may be generated <em>synchronously</em> or <em>asynchronously</em>. A
synchronous signal pertains to a specific action in the program, and is
delivered (unless blocked) during that action. Most errors generate
signals synchronously, and so do explicit requests by a process to
generate a signal for that same process. On some machines, certain
kinds of hardware errors (usually floating-point exceptions) are not
reported completely synchronously, but may arrive a few instructions
later.
</p>
<p>Asynchronous signals are generated by events outside the control of the
process that receives them. These signals arrive at unpredictable times
during execution. External events generate signals asynchronously, and
so do explicit requests that apply to some other process.
</p>
<p>A given type of signal is either typically synchronous or typically
asynchronous. For example, signals for errors are typically synchronous
because errors generate signals synchronously. But any type of signal
can be generated synchronously or asynchronously with an explicit
request.
</p>
<hr size="6">
<a name="Delivery-of-Signal"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Signal-Generation" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Standard-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Concepts-of-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="How-Signals-Are-Delivered"></a>
<h3 class="subsection">24.1.3 How Signals Are Delivered</h3>
<a name="index-delivery-of-signals"></a>
<a name="index-pending-signals"></a>
<a name="index-blocked-signals"></a>
<p>When a signal is generated, it becomes <em>pending</em>. Normally it
remains pending for just a short period of time and then is
<em>delivered</em> to the process that was signaled. However, if that kind
of signal is currently <em>blocked</em>, it may remain pending
indefinitely—until signals of that kind are <em>unblocked</em>. Once
unblocked, it will be delivered immediately. See section <a href="#Blocking-Signals">Blocking Signals</a>.
</p>
<a name="index-specified-action-_0028for-a-signal_0029"></a>
<a name="index-default-action-_0028for-a-signal_0029"></a>
<a name="index-signal-action"></a>
<a name="index-catching-signals"></a>
<p>When the signal is delivered, whether right away or after a long delay,
the <em>specified action</em> for that signal is taken. For certain
signals, such as <code>SIGKILL</code> and <code>SIGSTOP</code>, the action is fixed,
but for most signals, the program has a choice: ignore the signal,
specify a <em>handler function</em>, or accept the <em>default action</em> for
that kind of signal. The program specifies its choice using functions
such as <code>signal</code> or <code>sigaction</code> (see section <a href="#Signal-Actions">Specifying Signal Actions</a>). We
sometimes say that a handler <em>catches</em> the signal. While the
handler is running, that particular signal is normally blocked.
</p>
<p>If the specified action for a kind of signal is to ignore it, then any
such signal which is generated is discarded immediately. This happens
even if the signal is also blocked at the time. A signal discarded in
this way will never be delivered, not even if the program subsequently
specifies a different action for that kind of signal and then unblocks
it.
</p>
<p>If a signal arrives which the program has neither handled nor ignored,
its <em>default action</em> takes place. Each kind of signal has its own
default action, documented below (see section <a href="#Standard-Signals">Standard Signals</a>). For most kinds
of signals, the default action is to terminate the process. For certain
kinds of signals that represent “harmless” events, the default action
is to do nothing.
</p>
<p>When a signal terminates a process, its parent process can determine the
cause of termination by examining the termination status code reported
by the <code>wait</code> or <code>waitpid</code> functions. (This is discussed in
more detail in <a href="libc_26.html#Process-Completion">Process Completion</a>.) The information it can get
includes the fact that termination was due to a signal and the kind of
signal involved. If a program you run from a shell is terminated by a
signal, the shell typically prints some kind of error message.
</p>
<p>The signals that normally represent program errors have a special
property: when one of these signals terminates the process, it also
writes a <em>core dump file</em> which records the state of the process at
the time of termination. You can examine the core dump with a debugger
to investigate what caused the error.
</p>
<p>If you raise a “program error” signal by explicit request, and this
terminates the process, it makes a core dump file just as if the signal
had been due directly to an error.
</p>
<hr size="6">
<a name="Standard-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Delivery-of-Signal" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Program-Error-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Standard-Signals-1"></a>
<h2 class="section">24.2 Standard Signals</h2>
<a name="index-signal-names"></a>
<a name="index-names-of-signals"></a>
<a name="index-signal_002eh-1"></a>
<a name="index-signal-number"></a>
<p>This section lists the names for various standard kinds of signals and
describes what kind of event they mean. Each signal name is a macro
which stands for a positive integer—the <em>signal number</em> for that
kind of signal. Your programs should never make assumptions about the
numeric code for a particular kind of signal, but rather refer to them
always by the names defined here. This is because the number for a
given kind of signal can vary from system to system, but the meanings of
the names are standardized and fairly uniform.
</p>
<p>The signal names are defined in the header file ‘<tt>signal.h</tt>’.
</p>
<dl>
<dt><a name="index-NSIG"></a><u>Macro:</u> int <b>NSIG</b></dt>
<dd><p>The value of this symbolic constant is the total number of signals
defined. Since the signal numbers are allocated consecutively,
<code>NSIG</code> is also one greater than the largest defined signal number.
</p></dd></dl>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#Program-Error-Signals">24.2.1 Program Error Signals</a></td><td> </td><td align="left" valign="top"> Used to report serious program errors.
</td></tr>
<tr><td align="left" valign="top"><a href="#Termination-Signals">24.2.2 Termination Signals</a></td><td> </td><td align="left" valign="top"> Used to interrupt and/or terminate the
program.
</td></tr>
<tr><td align="left" valign="top"><a href="#Alarm-Signals">24.2.3 Alarm Signals</a></td><td> </td><td align="left" valign="top"> Used to indicate expiration of timers.
</td></tr>
<tr><td align="left" valign="top"><a href="#Asynchronous-I_002fO-Signals">24.2.4 Asynchronous I/O Signals</a></td><td> </td><td align="left" valign="top"> Used to indicate input is available.
</td></tr>
<tr><td align="left" valign="top"><a href="#Job-Control-Signals">24.2.5 Job Control Signals</a></td><td> </td><td align="left" valign="top"> Signals used to support job control.
</td></tr>
<tr><td align="left" valign="top"><a href="#Operation-Error-Signals">24.2.6 Operation Error Signals</a></td><td> </td><td align="left" valign="top"> Used to report operational system errors.
</td></tr>
<tr><td align="left" valign="top"><a href="#Miscellaneous-Signals">24.2.7 Miscellaneous Signals</a></td><td> </td><td align="left" valign="top"></td></tr>
<tr><td align="left" valign="top"><a href="#Signal-Messages">24.2.8 Signal Messages</a></td><td> </td><td align="left" valign="top"> Printing a message describing a signal.
</td></tr>
</table>
<hr size="6">
<a name="Program-Error-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Standard-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Termination-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Standard-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Program-Error-Signals-1"></a>
<h3 class="subsection">24.2.1 Program Error Signals</h3>
<a name="index-program-error-signals"></a>
<p>The following signals are generated when a serious program error is
detected by the operating system or the computer itself. In general,
all of these signals are indications that your program is seriously
broken in some way, and there’s usually no way to continue the
computation which encountered the error.
</p>
<p>Some programs handle program error signals in order to tidy up before
terminating; for example, programs that turn off echoing of terminal
input should handle program error signals in order to turn echoing back
on. The handler should end by specifying the default action for the
signal that happened and then reraising it; this will cause the program
to terminate with that signal, as if it had not had a handler.
(See section <a href="#Termination-in-Handler">Handlers That Terminate the Process</a>.)
</p>
<p>Termination is the sensible ultimate outcome from a program error in
most programs. However, programming systems such as Lisp that can load
compiled user programs might need to keep executing even if a user
program incurs an error. These programs have handlers which use
<code>longjmp</code> to return control to the command level.
</p>
<p>The default action for all of these signals is to cause the process to
terminate. If you block or ignore these signals or establish handlers
for them that return normally, your program will probably break horribly
when such signals happen, unless they are generated by <code>raise</code> or
<code>kill</code> instead of a real error.
</p>
<a name="index-COREFILE"></a>
<p>When one of these program error signals terminates a process, it also
writes a <em>core dump file</em> which records the state of the process at
the time of termination. The core dump file is named ‘<tt>core</tt>’ and is
written in whichever directory is current in the process at the time.
(On the GNU system, you can specify the file name for core dumps with
the environment variable <code>COREFILE</code>.) The purpose of core dump
files is so that you can examine them with a debugger to investigate
what caused the error.
</p>
<dl>
<dt><a name="index-SIGFPE"></a><u>Macro:</u> int <b>SIGFPE</b></dt>
<dd><p>The <code>SIGFPE</code> signal reports a fatal arithmetic error. Although the
name is derived from “floating-point exception”, this signal actually
covers all arithmetic errors, including division by zero and overflow.
If a program stores integer data in a location which is then used in a
floating-point operation, this often causes an “invalid operation”
exception, because the processor cannot recognize the data as a
floating-point number.
<a name="index-exception-1"></a>
<a name="index-floating_002dpoint-exception"></a>
</p>
<p>Actual floating-point exceptions are a complicated subject because there
are many types of exceptions with subtly different meanings, and the
<code>SIGFPE</code> signal doesn’t distinguish between them. The <cite>IEEE
Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985
and ANSI/IEEE Std 854-1987)</cite>
defines various floating-point exceptions and requires conforming
computer systems to report their occurrences. However, this standard
does not specify how the exceptions are reported, or what kinds of
handling and control the operating system can offer to the programmer.
</p></dd></dl>
<p>BSD systems provide the <code>SIGFPE</code> handler with an extra argument
that distinguishes various causes of the exception. In order to access
this argument, you must define the handler to accept two arguments,
which means you must cast it to a one-argument function type in order to
establish the handler. The GNU library does provide this extra
argument, but the value is meaningful only on operating systems that
provide the information (BSD systems and GNU systems).
</p>
<dl compact="compact">
<dt> <code>FPE_INTOVF_TRAP</code></dt>
<dd><a name="index-FPE_005fINTOVF_005fTRAP"></a>
<p>Integer overflow (impossible in a C program unless you enable overflow
trapping in a hardware-specific fashion).
</p></dd>
<dt> <code>FPE_INTDIV_TRAP</code></dt>
<dd><a name="index-FPE_005fINTDIV_005fTRAP"></a>
<p>Integer division by zero.
</p></dd>
<dt> <code>FPE_SUBRNG_TRAP</code></dt>
<dd><a name="index-FPE_005fSUBRNG_005fTRAP"></a>
<p>Subscript-range (something that C programs never check for).
</p></dd>
<dt> <code>FPE_FLTOVF_TRAP</code></dt>
<dd><a name="index-FPE_005fFLTOVF_005fTRAP"></a>
<p>Floating overflow trap.
</p></dd>
<dt> <code>FPE_FLTDIV_TRAP</code></dt>
<dd><a name="index-FPE_005fFLTDIV_005fTRAP"></a>
<p>Floating/decimal division by zero.
</p></dd>
<dt> <code>FPE_FLTUND_TRAP</code></dt>
<dd><a name="index-FPE_005fFLTUND_005fTRAP"></a>
<p>Floating underflow trap. (Trapping on floating underflow is not
normally enabled.)
</p></dd>
<dt> <code>FPE_DECOVF_TRAP</code></dt>
<dd><a name="index-FPE_005fDECOVF_005fTRAP"></a>
<p>Decimal overflow trap. (Only a few machines have decimal arithmetic and
C never uses it.)
</p></dd>
</dl>
<dl>
<dt><a name="index-SIGILL"></a><u>Macro:</u> int <b>SIGILL</b></dt>
<dd><p>The name of this signal is derived from “illegal instruction”; it
usually means your program is trying to execute garbage or a privileged
instruction. Since the C compiler generates only valid instructions,
<code>SIGILL</code> typically indicates that the executable file is corrupted,
or that you are trying to execute data. Some common ways of getting
into the latter situation are by passing an invalid object where a
pointer to a function was expected, or by writing past the end of an
automatic array (or similar problems with pointers to automatic
variables) and corrupting other data on the stack such as the return
address of a stack frame.
</p>
<p><code>SIGILL</code> can also be generated when the stack overflows, or when
the system has trouble running the handler for a signal.
</p></dd></dl>
<a name="index-illegal-instruction"></a>
<dl>
<dt><a name="index-SIGSEGV"></a><u>Macro:</u> int <b>SIGSEGV</b></dt>
<dd><a name="index-segmentation-violation"></a>
<p>This signal is generated when a program tries to read or write outside
the memory that is allocated for it, or to write memory that can only be
read. (Actually, the signals only occur when the program goes far
enough outside to be detected by the system’s memory protection
mechanism.) The name is an abbreviation for “segmentation violation”.
</p>
<p>Common ways of getting a <code>SIGSEGV</code> condition include dereferencing
a null or uninitialized pointer, or when you use a pointer to step
through an array, but fail to check for the end of the array. It varies
among systems whether dereferencing a null pointer generates
<code>SIGSEGV</code> or <code>SIGBUS</code>.
</p></dd></dl>
<dl>
<dt><a name="index-SIGBUS"></a><u>Macro:</u> int <b>SIGBUS</b></dt>
<dd><p>This signal is generated when an invalid pointer is dereferenced. Like
<code>SIGSEGV</code>, this signal is typically the result of dereferencing an
uninitialized pointer. The difference between the two is that
<code>SIGSEGV</code> indicates an invalid access to valid memory, while
<code>SIGBUS</code> indicates an access to an invalid address. In particular,
<code>SIGBUS</code> signals often result from dereferencing a misaligned
pointer, such as referring to a four-word integer at an address not
divisible by four. (Each kind of computer has its own requirements for
address alignment.)
</p>
<p>The name of this signal is an abbreviation for “bus error”.
</p></dd></dl>
<a name="index-bus-error"></a>
<dl>
<dt><a name="index-SIGABRT"></a><u>Macro:</u> int <b>SIGABRT</b></dt>
<dd><a name="index-abort-signal"></a>
<p>This signal indicates an error detected by the program itself and
reported by calling <code>abort</code>. See section <a href="libc_25.html#Aborting-a-Program">Aborting a Program</a>.
</p></dd></dl>
<dl>
<dt><a name="index-SIGIOT"></a><u>Macro:</u> int <b>SIGIOT</b></dt>
<dd><p>Generated by the PDP-11 “iot” instruction. On most machines, this is
just another name for <code>SIGABRT</code>.
</p></dd></dl>
<dl>
<dt><a name="index-SIGTRAP"></a><u>Macro:</u> int <b>SIGTRAP</b></dt>
<dd><p>Generated by the machine’s breakpoint instruction, and possibly other
trap instructions. This signal is used by debuggers. Your program will
probably only see <code>SIGTRAP</code> if it is somehow executing bad
instructions.
</p></dd></dl>
<dl>
<dt><a name="index-SIGEMT"></a><u>Macro:</u> int <b>SIGEMT</b></dt>
<dd><p>Emulator trap; this results from certain unimplemented instructions
which might be emulated in software, or the operating system’s
failure to properly emulate them.
</p></dd></dl>
<dl>
<dt><a name="index-SIGSYS"></a><u>Macro:</u> int <b>SIGSYS</b></dt>
<dd><p>Bad system call; that is to say, the instruction to trap to the
operating system was executed, but the code number for the system call
to perform was invalid.
</p></dd></dl>
<hr size="6">
<a name="Termination-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Program-Error-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Alarm-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Standard-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Termination-Signals-1"></a>
<h3 class="subsection">24.2.2 Termination Signals</h3>
<a name="index-program-termination-signals"></a>
<p>These signals are all used to tell a process to terminate, in one way
or another. They have different names because they’re used for slightly
different purposes, and programs might want to handle them differently.
</p>
<p>The reason for handling these signals is usually so your program can
tidy up as appropriate before actually terminating. For example, you
might want to save state information, delete temporary files, or restore
the previous terminal modes. Such a handler should end by specifying
the default action for the signal that happened and then reraising it;
this will cause the program to terminate with that signal, as if it had
not had a handler. (See section <a href="#Termination-in-Handler">Handlers That Terminate the Process</a>.)
</p>
<p>The (obvious) default action for all of these signals is to cause the
process to terminate.
</p>
<dl>
<dt><a name="index-SIGTERM"></a><u>Macro:</u> int <b>SIGTERM</b></dt>
<dd><a name="index-termination-signal"></a>
<p>The <code>SIGTERM</code> signal is a generic signal used to cause program
termination. Unlike <code>SIGKILL</code>, this signal can be blocked,
handled, and ignored. It is the normal way to politely ask a program to
terminate.
</p>
<p>The shell command <code>kill</code> generates <code>SIGTERM</code> by default.
<a name="index-kill"></a>
</p></dd></dl>
<dl>
<dt><a name="index-SIGINT"></a><u>Macro:</u> int <b>SIGINT</b></dt>
<dd><a name="index-interrupt-signal"></a>
<p>The <code>SIGINT</code> (“program interrupt”) signal is sent when the user
types the INTR character (normally <kbd>C-c</kbd>). See section <a href="libc_17.html#Special-Characters">Special Characters</a>, for information about terminal driver support for
<kbd>C-c</kbd>.
</p></dd></dl>
<dl>
<dt><a name="index-SIGQUIT"></a><u>Macro:</u> int <b>SIGQUIT</b></dt>
<dd><a name="index-quit-signal"></a>
<a name="index-quit-signal-1"></a>
<p>The <code>SIGQUIT</code> signal is similar to <code>SIGINT</code>, except that it’s
controlled by a different key—the QUIT character, usually
<kbd>C-\</kbd>—and produces a core dump when it terminates the process,
just like a program error signal. You can think of this as a
program error condition “detected” by the user.
</p>
<p>See section <a href="#Program-Error-Signals">Program Error Signals</a>, for information about core dumps.
See section <a href="libc_17.html#Special-Characters">Special Characters</a>, for information about terminal driver
support.
</p>
<p>Certain kinds of cleanups are best omitted in handling <code>SIGQUIT</code>.
For example, if the program creates temporary files, it should handle
the other termination requests by deleting the temporary files. But it
is better for <code>SIGQUIT</code> not to delete them, so that the user can
examine them in conjunction with the core dump.
</p></dd></dl>
<dl>
<dt><a name="index-SIGKILL"></a><u>Macro:</u> int <b>SIGKILL</b></dt>
<dd><p>The <code>SIGKILL</code> signal is used to cause immediate program termination.
It cannot be handled or ignored, and is therefore always fatal. It is
also not possible to block this signal.
</p>
<p>This signal is usually generated only by explicit request. Since it
cannot be handled, you should generate it only as a last resort, after
first trying a less drastic method such as <kbd>C-c</kbd> or <code>SIGTERM</code>.
If a process does not respond to any other termination signals, sending
it a <code>SIGKILL</code> signal will almost always cause it to go away.
</p>
<p>In fact, if <code>SIGKILL</code> fails to terminate a process, that by itself
constitutes an operating system bug which you should report.
</p>
<p>The system will generate <code>SIGKILL</code> for a process itself under some
unusual conditions where the program cannot possibly continue to run
(even to run a signal handler).
</p></dd></dl>
<a name="index-kill-signal"></a>
<dl>
<dt><a name="index-SIGHUP"></a><u>Macro:</u> int <b>SIGHUP</b></dt>
<dd><a name="index-hangup-signal"></a>
<p>The <code>SIGHUP</code> (“hang-up”) signal is used to report that the user’s
terminal is disconnected, perhaps because a network or telephone
connection was broken. For more information about this, see <a href="libc_17.html#Control-Modes">Control Modes</a>.
</p>
<p>This signal is also used to report the termination of the controlling
process on a terminal to jobs associated with that session; this
termination effectively disconnects all processes in the session from
the controlling terminal. For more information, see <a href="libc_25.html#Termination-Internals">Termination Internals</a>.
</p></dd></dl>
<hr size="6">
<a name="Alarm-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Termination-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Asynchronous-I_002fO-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Standard-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Alarm-Signals-1"></a>
<h3 class="subsection">24.2.3 Alarm Signals</h3>
<p>These signals are used to indicate the expiration of timers.
See section <a href="libc_21.html#Setting-an-Alarm">Setting an Alarm</a>, for information about functions that cause
these signals to be sent.
</p>
<p>The default behavior for these signals is to cause program termination.
This default is rarely useful, but no other default would be useful;
most of the ways of using these signals would require handler functions
in any case.
</p>
<dl>
<dt><a name="index-SIGALRM"></a><u>Macro:</u> int <b>SIGALRM</b></dt>
<dd><p>This signal typically indicates expiration of a timer that measures real
or clock time. It is used by the <code>alarm</code> function, for example.
</p></dd></dl>
<a name="index-alarm-signal"></a>
<dl>
<dt><a name="index-SIGVTALRM"></a><u>Macro:</u> int <b>SIGVTALRM</b></dt>
<dd><p>This signal typically indicates expiration of a timer that measures CPU
time used by the current process. The name is an abbreviation for
“virtual time alarm”.
</p></dd></dl>
<a name="index-virtual-time-alarm-signal"></a>
<dl>
<dt><a name="index-SIGPROF"></a><u>Macro:</u> int <b>SIGPROF</b></dt>
<dd><p>This signal typically indicates expiration of a timer that measures
both CPU time used by the current process, and CPU time expended on
behalf of the process by the system. Such a timer is used to implement
code profiling facilities, hence the name of this signal.
</p></dd></dl>
<a name="index-profiling-alarm-signal"></a>
<hr size="6">
<a name="Asynchronous-I_002fO-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Alarm-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Job-Control-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Standard-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Asynchronous-I_002fO-Signals-1"></a>
<h3 class="subsection">24.2.4 Asynchronous I/O Signals</h3>
<p>The signals listed in this section are used in conjunction with
asynchronous I/O facilities. You have to take explicit action by
calling <code>fcntl</code> to enable a particular file descriptor to generate
these signals (see section <a href="libc_13.html#Interrupt-Input">Interrupt-Driven Input</a>). The default action for these
signals is to ignore them.
</p>
<dl>
<dt><a name="index-SIGIO"></a><u>Macro:</u> int <b>SIGIO</b></dt>
<dd><a name="index-input-available-signal"></a>
<a name="index-output-possible-signal"></a>
<p>This signal is sent when a file descriptor is ready to perform input
or output.
</p>
<p>On most operating systems, terminals and sockets are the only kinds of
files that can generate <code>SIGIO</code>; other kinds, including ordinary
files, never generate <code>SIGIO</code> even if you ask them to.
</p>
<p>In the GNU system <code>SIGIO</code> will always be generated properly
if you successfully set asynchronous mode with <code>fcntl</code>.
</p></dd></dl>
<dl>
<dt><a name="index-SIGURG"></a><u>Macro:</u> int <b>SIGURG</b></dt>
<dd><a name="index-urgent-data-signal"></a>
<p>This signal is sent when “urgent” or out-of-band data arrives on a
socket. See section <a href="libc_16.html#Out_002dof_002dBand-Data">Out-of-Band Data</a>.
</p></dd></dl>
<dl>
<dt><a name="index-SIGPOLL"></a><u>Macro:</u> int <b>SIGPOLL</b></dt>
<dd><p>This is a System V signal name, more or less similar to <code>SIGIO</code>.
It is defined only for compatibility.
</p></dd></dl>
<hr size="6">
<a name="Job-Control-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Asynchronous-I_002fO-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Operation-Error-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Standard-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Job-Control-Signals-1"></a>
<h3 class="subsection">24.2.5 Job Control Signals</h3>
<a name="index-job-control-signals"></a>
<p>These signals are used to support job control. If your system
doesn’t support job control, then these macros are defined but the
signals themselves can’t be raised or handled.
</p>
<p>You should generally leave these signals alone unless you really
understand how job control works. See section <a href="libc_27.html#Job-Control">Job Control</a>.
</p>
<dl>
<dt><a name="index-SIGCHLD"></a><u>Macro:</u> int <b>SIGCHLD</b></dt>
<dd><a name="index-child-process-signal"></a>
<p>This signal is sent to a parent process whenever one of its child
processes terminates or stops.
</p>
<p>The default action for this signal is to ignore it. If you establish a
handler for this signal while there are child processes that have
terminated but not reported their status via <code>wait</code> or
<code>waitpid</code> (see section <a href="libc_26.html#Process-Completion">Process Completion</a>), whether your new handler
applies to those processes or not depends on the particular operating
system.
</p></dd></dl>
<dl>
<dt><a name="index-SIGCLD"></a><u>Macro:</u> int <b>SIGCLD</b></dt>
<dd><p>This is an obsolete name for <code>SIGCHLD</code>.
</p></dd></dl>
<dl>
<dt><a name="index-SIGCONT"></a><u>Macro:</u> int <b>SIGCONT</b></dt>
<dd><a name="index-continue-signal"></a>
<p>You can send a <code>SIGCONT</code> signal to a process to make it continue.
This signal is special—it always makes the process continue if it is
stopped, before the signal is delivered. The default behavior is to do
nothing else. You cannot block this signal. You can set a handler, but
<code>SIGCONT</code> always makes the process continue regardless.
</p>
<p>Most programs have no reason to handle <code>SIGCONT</code>; they simply
resume execution without realizing they were ever stopped. You can use
a handler for <code>SIGCONT</code> to make a program do something special when
it is stopped and continued—for example, to reprint a prompt when it
is suspended while waiting for input.
</p></dd></dl>
<dl>
<dt><a name="index-SIGSTOP"></a><u>Macro:</u> int <b>SIGSTOP</b></dt>
<dd><p>The <code>SIGSTOP</code> signal stops the process. It cannot be handled,
ignored, or blocked.
</p></dd></dl>
<a name="index-stop-signal"></a>
<dl>
<dt><a name="index-SIGTSTP"></a><u>Macro:</u> int <b>SIGTSTP</b></dt>
<dd><p>The <code>SIGTSTP</code> signal is an interactive stop signal. Unlike
<code>SIGSTOP</code>, this signal can be handled and ignored.
</p>
<p>Your program should handle this signal if you have a special need to
leave files or system tables in a secure state when a process is
stopped. For example, programs that turn off echoing should handle
<code>SIGTSTP</code> so they can turn echoing back on before stopping.
</p>
<p>This signal is generated when the user types the SUSP character
(normally <kbd>C-z</kbd>). For more information about terminal driver
support, see <a href="libc_17.html#Special-Characters">Special Characters</a>.
</p></dd></dl>
<a name="index-interactive-stop-signal"></a>
<dl>
<dt><a name="index-SIGTTIN"></a><u>Macro:</u> int <b>SIGTTIN</b></dt>
<dd><p>A process cannot read from the user’s terminal while it is running
as a background job. When any process in a background job tries to
read from the terminal, all of the processes in the job are sent a
<code>SIGTTIN</code> signal. The default action for this signal is to
stop the process. For more information about how this interacts with
the terminal driver, see <a href="libc_27.html#Access-to-the-Terminal">Access to the Controlling Terminal</a>.
</p></dd></dl>
<a name="index-terminal-input-signal"></a>
<dl>
<dt><a name="index-SIGTTOU"></a><u>Macro:</u> int <b>SIGTTOU</b></dt>
<dd><p>This is similar to <code>SIGTTIN</code>, but is generated when a process in a
background job attempts to write to the terminal or set its modes.
Again, the default action is to stop the process. <code>SIGTTOU</code> is
only generated for an attempt to write to the terminal if the
<code>TOSTOP</code> output mode is set; see section <a href="libc_17.html#Output-Modes">Output Modes</a>.
</p></dd></dl>
<a name="index-terminal-output-signal"></a>
<p>While a process is stopped, no more signals can be delivered to it until
it is continued, except <code>SIGKILL</code> signals and (obviously)
<code>SIGCONT</code> signals. The signals are marked as pending, but not
delivered until the process is continued. The <code>SIGKILL</code> signal
always causes termination of the process and can’t be blocked, handled
or ignored. You can ignore <code>SIGCONT</code>, but it always causes the
process to be continued anyway if it is stopped. Sending a
<code>SIGCONT</code> signal to a process causes any pending stop signals for
that process to be discarded. Likewise, any pending <code>SIGCONT</code>
signals for a process are discarded when it receives a stop signal.
</p>
<p>When a process in an orphaned process group (see section <a href="libc_27.html#Orphaned-Process-Groups">Orphaned Process Groups</a>) receives a <code>SIGTSTP</code>, <code>SIGTTIN</code>, or <code>SIGTTOU</code>
signal and does not handle it, the process does not stop. Stopping the
process would probably not be very useful, since there is no shell
program that will notice it stop and allow the user to continue it.
What happens instead depends on the operating system you are using.
Some systems may do nothing; others may deliver another signal instead,
such as <code>SIGKILL</code> or <code>SIGHUP</code>. In the GNU system, the process
dies with <code>SIGKILL</code>; this avoids the problem of many stopped,
orphaned processes lying around the system.
</p>
<hr size="6">
<a name="Operation-Error-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Job-Control-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Miscellaneous-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Standard-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Operation-Error-Signals-1"></a>
<h3 class="subsection">24.2.6 Operation Error Signals</h3>
<p>These signals are used to report various errors generated by an
operation done by the program. They do not necessarily indicate a
programming error in the program, but an error that prevents an
operating system call from completing. The default action for all of
them is to cause the process to terminate.
</p>
<dl>
<dt><a name="index-SIGPIPE"></a><u>Macro:</u> int <b>SIGPIPE</b></dt>
<dd><a name="index-pipe-signal"></a>
<a name="index-broken-pipe-signal"></a>
<p>Broken pipe. If you use pipes or FIFOs, you have to design your
application so that one process opens the pipe for reading before
another starts writing. If the reading process never starts, or
terminates unexpectedly, writing to the pipe or FIFO raises a
<code>SIGPIPE</code> signal. If <code>SIGPIPE</code> is blocked, handled or
ignored, the offending call fails with <code>EPIPE</code> instead.
</p>
<p>Pipes and FIFO special files are discussed in more detail in <a href="libc_15.html#Pipes-and-FIFOs">Pipes and FIFOs</a>.
</p>
<p>Another cause of <code>SIGPIPE</code> is when you try to output to a socket
that isn’t connected. See section <a href="libc_16.html#Sending-Data">Sending Data</a>.
</p></dd></dl>
<dl>
<dt><a name="index-SIGLOST"></a><u>Macro:</u> int <b>SIGLOST</b></dt>
<dd><a name="index-lost-resource-signal"></a>
<p>Resource lost. This signal is generated when you have an advisory lock
on an NFS file, and the NFS server reboots and forgets about your lock.
</p>
<p>In the GNU system, <code>SIGLOST</code> is generated when any server program
dies unexpectedly. It is usually fine to ignore the signal; whatever
call was made to the server that died just returns an error.
</p></dd></dl>
<dl>
<dt><a name="index-SIGXCPU"></a><u>Macro:</u> int <b>SIGXCPU</b></dt>
<dd><p>CPU time limit exceeded. This signal is generated when the process
exceeds its soft resource limit on CPU time. See section <a href="libc_22.html#Limits-on-Resources">Limiting Resource Usage</a>.
</p></dd></dl>
<dl>
<dt><a name="index-SIGXFSZ"></a><u>Macro:</u> int <b>SIGXFSZ</b></dt>
<dd><p>File size limit exceeded. This signal is generated when the process
attempts to extend a file so it exceeds the process’s soft resource
limit on file size. See section <a href="libc_22.html#Limits-on-Resources">Limiting Resource Usage</a>.
</p></dd></dl>
<hr size="6">
<a name="Miscellaneous-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Operation-Error-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Messages" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Standard-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Miscellaneous-Signals-1"></a>
<h3 class="subsection">24.2.7 Miscellaneous Signals</h3>
<p>These signals are used for various other purposes. In general, they
will not affect your program unless it explicitly uses them for something.
</p>
<dl>
<dt><a name="index-SIGUSR1"></a><u>Macro:</u> int <b>SIGUSR1</b></dt>
<dt><a name="index-SIGUSR2"></a><u>Macro:</u> int <b>SIGUSR2</b></dt>
<dd><a name="index-user-signals"></a>
<p>The <code>SIGUSR1</code> and <code>SIGUSR2</code> signals are set aside for you to
use any way you want. They’re useful for simple interprocess
communication, if you write a signal handler for them in the program
that receives the signal.
</p>
<p>There is an example showing the use of <code>SIGUSR1</code> and <code>SIGUSR2</code>
in <a href="#Signaling-Another-Process">Signaling Another Process</a>.
</p>
<p>The default action is to terminate the process.
</p></dd></dl>
<dl>
<dt><a name="index-SIGWINCH"></a><u>Macro:</u> int <b>SIGWINCH</b></dt>
<dd><p>Window size change. This is generated on some systems (including GNU)
when the terminal driver’s record of the number of rows and columns on
the screen is changed. The default action is to ignore it.
</p>
<p>If a program does full-screen display, it should handle <code>SIGWINCH</code>.
When the signal arrives, it should fetch the new screen size and
reformat its display accordingly.
</p></dd></dl>
<dl>
<dt><a name="index-SIGINFO"></a><u>Macro:</u> int <b>SIGINFO</b></dt>
<dd><p>Information request. In 4.4 BSD and the GNU system, this signal is sent
to all the processes in the foreground process group of the controlling
terminal when the user types the STATUS character in canonical mode;
see section <a href="libc_17.html#Signal-Characters">Characters that Cause Signals</a>.
</p>
<p>If the process is the leader of the process group, the default action is
to print some status information about the system and what the process
is doing. Otherwise the default is to do nothing.
</p></dd></dl>
<hr size="6">
<a name="Signal-Messages"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Miscellaneous-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Actions" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Standard-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Signal-Messages-1"></a>
<h3 class="subsection">24.2.8 Signal Messages</h3>
<a name="index-signal-messages"></a>
<p>We mentioned above that the shell prints a message describing the signal
that terminated a child process. The clean way to print a message
describing a signal is to use the functions <code>strsignal</code> and
<code>psignal</code>. These functions use a signal number to specify which
kind of signal to describe. The signal number may come from the
termination status of a child process (see section <a href="libc_26.html#Process-Completion">Process Completion</a>) or it
may come from a signal handler in the same process.
</p>
<dl>
<dt><a name="index-strsignal"></a><u>Function:</u> char * <b>strsignal</b><i> (int <var>signum</var>)</i></dt>
<dd><p>This function returns a pointer to a statically-allocated string
containing a message describing the signal <var>signum</var>. You
should not modify the contents of this string; and, since it can be
rewritten on subsequent calls, you should save a copy of it if you need
to reference it later.
</p>
<a name="index-string_002eh-7"></a>
<p>This function is a GNU extension, declared in the header file
‘<tt>string.h</tt>’.
</p></dd></dl>
<dl>
<dt><a name="index-psignal"></a><u>Function:</u> void <b>psignal</b><i> (int <var>signum</var>, const char *<var>message</var>)</i></dt>
<dd><p>This function prints a message describing the signal <var>signum</var> to the
standard error output stream <code>stderr</code>; see <a href="libc_12.html#Standard-Streams">Standard Streams</a>.
</p>
<p>If you call <code>psignal</code> with a <var>message</var> that is either a null
pointer or an empty string, <code>psignal</code> just prints the message
corresponding to <var>signum</var>, adding a trailing newline.
</p>
<p>If you supply a non-null <var>message</var> argument, then <code>psignal</code>
prefixes its output with this string. It adds a colon and a space
character to separate the <var>message</var> from the string corresponding
to <var>signum</var>.
</p>
<a name="index-stdio_002eh-18"></a>
<p>This function is a BSD feature, declared in the header file ‘<tt>signal.h</tt>’.
</p></dd></dl>
<a name="index-sys_005fsiglist"></a>
<p>There is also an array <code>sys_siglist</code> which contains the messages
for the various signal codes. This array exists on BSD systems, unlike
<code>strsignal</code>.
</p>
<hr size="6">
<a name="Signal-Actions"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Signal-Messages" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Basic-Signal-Handling" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Specifying-Signal-Actions"></a>
<h2 class="section">24.3 Specifying Signal Actions</h2>
<a name="index-signal-actions"></a>
<a name="index-establishing-a-handler"></a>
<p>The simplest way to change the action for a signal is to use the
<code>signal</code> function. You can specify a built-in action (such as to
ignore the signal), or you can <em>establish a handler</em>.
</p>
<p>The GNU library also implements the more versatile <code>sigaction</code>
facility. This section describes both facilities and gives suggestions
on which to use when.
</p>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#Basic-Signal-Handling">24.3.1 Basic Signal Handling</a></td><td> </td><td align="left" valign="top"> The simple <code>signal</code> function.
</td></tr>
<tr><td align="left" valign="top"><a href="#Advanced-Signal-Handling">24.3.2 Advanced Signal Handling</a></td><td> </td><td align="left" valign="top"> The more powerful <code>sigaction</code> function.
</td></tr>
<tr><td align="left" valign="top"><a href="#Signal-and-Sigaction">24.3.3 Interaction of <code>signal</code> and <code>sigaction</code></a></td><td> </td><td align="left" valign="top"> How those two functions interact.
</td></tr>
<tr><td align="left" valign="top"><a href="#Sigaction-Function-Example">24.3.4 <code>sigaction</code> Function Example</a></td><td> </td><td align="left" valign="top"> An example of using the sigaction function.
</td></tr>
<tr><td align="left" valign="top"><a href="#Flags-for-Sigaction">24.3.5 Flags for <code>sigaction</code></a></td><td> </td><td align="left" valign="top"> Specifying options for signal handling.
</td></tr>
<tr><td align="left" valign="top"><a href="#Initial-Signal-Actions">24.3.6 Initial Signal Actions</a></td><td> </td><td align="left" valign="top"> How programs inherit signal actions.
</td></tr>
</table>
<hr size="6">
<a name="Basic-Signal-Handling"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Signal-Actions" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Advanced-Signal-Handling" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Actions" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Basic-Signal-Handling-1"></a>
<h3 class="subsection">24.3.1 Basic Signal Handling</h3>
<a name="index-signal-function"></a>
<p>The <code>signal</code> function provides a simple interface for establishing
an action for a particular signal. The function and associated macros
are declared in the header file ‘<tt>signal.h</tt>’.
<a name="index-signal_002eh-2"></a>
</p>
<dl>
<dt><a name="index-sighandler_005ft"></a><u>Data Type:</u> <b>sighandler_t</b></dt>
<dd><p>This is the type of signal handler functions. Signal handlers take one
integer argument specifying the signal number, and have return type
<code>void</code>. So, you should define handler functions like this:
</p>
<table><tr><td> </td><td><pre class="smallexample">void <var>handler</var> (int <code>signum</code>) { … }
</pre></td></tr></table>
<p>The name <code>sighandler_t</code> for this data type is a GNU extension.
</p></dd></dl>
<dl>
<dt><a name="index-signal-2"></a><u>Function:</u> sighandler_t <b>signal</b><i> (int <var>signum</var>, sighandler_t <var>action</var>)</i></dt>
<dd><p>The <code>signal</code> function establishes <var>action</var> as the action for
the signal <var>signum</var>.
</p>
<p>The first argument, <var>signum</var>, identifies the signal whose behavior
you want to control, and should be a signal number. The proper way to
specify a signal number is with one of the symbolic signal names
(see section <a href="#Standard-Signals">Standard Signals</a>)—don’t use an explicit number, because
the numerical code for a given kind of signal may vary from operating
system to operating system.
</p>
<p>The second argument, <var>action</var>, specifies the action to use for the
signal <var>signum</var>. This can be one of the following:
</p>
<dl compact="compact">
<dt> <code>SIG_DFL</code></dt>
<dd><a name="index-SIG_005fDFL"></a>
<a name="index-default-action-for-a-signal"></a>
<p><code>SIG_DFL</code> specifies the default action for the particular signal.
The default actions for various kinds of signals are stated in
<a href="#Standard-Signals">Standard Signals</a>.
</p>
</dd>
<dt> <code>SIG_IGN</code></dt>
<dd><a name="index-SIG_005fIGN"></a>
<a name="index-ignore-action-for-a-signal"></a>
<p><code>SIG_IGN</code> specifies that the signal should be ignored.
</p>
<p>Your program generally should not ignore signals that represent serious
events or that are normally used to request termination. You cannot
ignore the <code>SIGKILL</code> or <code>SIGSTOP</code> signals at all. You can
ignore program error signals like <code>SIGSEGV</code>, but ignoring the error
won’t enable the program to continue executing meaningfully. Ignoring
user requests such as <code>SIGINT</code>, <code>SIGQUIT</code>, and <code>SIGTSTP</code>
is unfriendly.
</p>
<p>When you do not wish signals to be delivered during a certain part of
the program, the thing to do is to block them, not ignore them.
See section <a href="#Blocking-Signals">Blocking Signals</a>.
</p>
</dd>
<dt> <code><var>handler</var></code></dt>
<dd><p>Supply the address of a handler function in your program, to specify
running this handler as the way to deliver the signal.
</p>
<p>For more information about defining signal handler functions,
see <a href="#Defining-Handlers">Defining Signal Handlers</a>.
</p></dd>
</dl>
<p>If you set the action for a signal to <code>SIG_IGN</code>, or if you set it
to <code>SIG_DFL</code> and the default action is to ignore that signal, then
any pending signals of that type are discarded (even if they are
blocked). Discarding the pending signals means that they will never be
delivered, not even if you subsequently specify another action and
unblock this kind of signal.
</p>
<p>The <code>signal</code> function returns the action that was previously in
effect for the specified <var>signum</var>. You can save this value and
restore it later by calling <code>signal</code> again.
</p>
<p>If <code>signal</code> can’t honor the request, it returns <code>SIG_ERR</code>
instead. The following <code>errno</code> error conditions are defined for
this function:
</p>
<dl compact="compact">
<dt> <code>EINVAL</code></dt>
<dd><p>You specified an invalid <var>signum</var>; or you tried to ignore or provide
a handler for <code>SIGKILL</code> or <code>SIGSTOP</code>.
</p></dd>
</dl>
</dd></dl>
<p><strong>Compatibility Note:</strong> A problem encountered when working with the
<code>signal</code> function is that it has different semantics on BSD and
SVID systems. The difference is that on SVID systems the signal handler
is deinstalled after signal delivery. On BSD systems the
handler must be explicitly deinstalled. In the GNU C Library we use the
BSD version by default. To use the SVID version you can either use the
function <code>sysv_signal</code> (see below) or use the <code>_XOPEN_SOURCE</code>
feature select macro (see section <a href="libc_1.html#Feature-Test-Macros">Feature Test Macros</a>). In general, use of these
functions should be avoided because of compatibility problems. It
is better to use <code>sigaction</code> if it is available since the results
are much more reliable.
</p>
<p>Here is a simple example of setting up a handler to delete temporary
files when certain fatal signals happen:
</p>
<table><tr><td> </td><td><pre class="smallexample">#include <signal.h>
void
termination_handler (int signum)
{
struct temp_file *p;
for (p = temp_file_list; p; p = p->next)
unlink (p->name);
}
int
main (void)
{
…
if (signal (SIGINT, termination_handler) == SIG_IGN)
signal (SIGINT, SIG_IGN);
if (signal (SIGHUP, termination_handler) == SIG_IGN)
signal (SIGHUP, SIG_IGN);
if (signal (SIGTERM, termination_handler) == SIG_IGN)
signal (SIGTERM, SIG_IGN);
…
}
</pre></td></tr></table>
<p>Note that if a given signal was previously set to be ignored, this code
avoids altering that setting. This is because non-job-control shells
often ignore certain signals when starting children, and it is important
for the children to respect this.
</p>
<p>We do not handle <code>SIGQUIT</code> or the program error signals in this
example because these are designed to provide information for debugging
(a core dump), and the temporary files may give useful information.
</p>
<dl>
<dt><a name="index-sysv_005fsignal"></a><u>Function:</u> sighandler_t <b>sysv_signal</b><i> (int <var>signum</var>, sighandler_t <var>action</var>)</i></dt>
<dd><p>The <code>sysv_signal</code> implements the behavior of the standard
<code>signal</code> function as found on SVID systems. The difference to BSD
systems is that the handler is deinstalled after a delivery of a signal.
</p>
<p><strong>Compatibility Note:</strong> As said above for <code>signal</code>, this
function should be avoided when possible. <code>sigaction</code> is the
preferred method.
</p></dd></dl>
<dl>
<dt><a name="index-ssignal"></a><u>Function:</u> sighandler_t <b>ssignal</b><i> (int <var>signum</var>, sighandler_t <var>action</var>)</i></dt>
<dd><p>The <code>ssignal</code> function does the same thing as <code>signal</code>; it is
provided only for compatibility with SVID.
</p></dd></dl>
<dl>
<dt><a name="index-SIG_005fERR"></a><u>Macro:</u> sighandler_t <b>SIG_ERR</b></dt>
<dd><p>The value of this macro is used as the return value from <code>signal</code>
to indicate an error.
</p></dd></dl>
<hr size="6">
<a name="Advanced-Signal-Handling"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Basic-Signal-Handling" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-and-Sigaction" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Actions" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Advanced-Signal-Handling-1"></a>
<h3 class="subsection">24.3.2 Advanced Signal Handling</h3>
<a name="index-sigaction-function"></a>
<p>The <code>sigaction</code> function has the same basic effect as
<code>signal</code>: to specify how a signal should be handled by the process.
However, <code>sigaction</code> offers more control, at the expense of more
complexity. In particular, <code>sigaction</code> allows you to specify
additional flags to control when the signal is generated and how the
handler is invoked.
</p>
<p>The <code>sigaction</code> function is declared in ‘<tt>signal.h</tt>’.
<a name="index-signal_002eh-3"></a>
</p>
<dl>
<dt><a name="index-struct-sigaction"></a><u>Data Type:</u> <b>struct sigaction</b></dt>
<dd><p>Structures of type <code>struct sigaction</code> are used in the
<code>sigaction</code> function to specify all the information about how to
handle a particular signal. This structure contains at least the
following members:
</p>
<dl compact="compact">
<dt> <code>sighandler_t sa_handler</code></dt>
<dd><p>This is used in the same way as the <var>action</var> argument to the
<code>signal</code> function. The value can be <code>SIG_DFL</code>,
<code>SIG_IGN</code>, or a function pointer. See section <a href="#Basic-Signal-Handling">Basic Signal Handling</a>.
</p>
</dd>
<dt> <code>sigset_t sa_mask</code></dt>
<dd><p>This specifies a set of signals to be blocked while the handler runs.
Blocking is explained in <a href="#Blocking-for-Handler">Blocking Signals for a Handler</a>. Note that the
signal that was delivered is automatically blocked by default before its
handler is started; this is true regardless of the value in
<code>sa_mask</code>. If you want that signal not to be blocked within its
handler, you must write code in the handler to unblock it.
</p>
</dd>
<dt> <code>int sa_flags</code></dt>
<dd><p>This specifies various flags which can affect the behavior of
the signal. These are described in more detail in <a href="#Flags-for-Sigaction">Flags for <code>sigaction</code></a>.
</p></dd>
</dl>
</dd></dl>
<dl>
<dt><a name="index-sigaction"></a><u>Function:</u> int <b>sigaction</b><i> (int <var>signum</var>, const struct sigaction *restrict <var>action</var>, struct sigaction *restrict <var>old-action</var>)</i></dt>
<dd><p>The <var>action</var> argument is used to set up a new action for the signal
<var>signum</var>, while the <var>old-action</var> argument is used to return
information about the action previously associated with this symbol.
(In other words, <var>old-action</var> has the same purpose as the
<code>signal</code> function’s return value—you can check to see what the
old action in effect for the signal was, and restore it later if you
want.)
</p>
<p>Either <var>action</var> or <var>old-action</var> can be a null pointer. If
<var>old-action</var> is a null pointer, this simply suppresses the return
of information about the old action. If <var>action</var> is a null pointer,
the action associated with the signal <var>signum</var> is unchanged; this
allows you to inquire about how a signal is being handled without changing
that handling.
</p>
<p>The return value from <code>sigaction</code> is zero if it succeeds, and
<code>-1</code> on failure. The following <code>errno</code> error conditions are
defined for this function:
</p>
<dl compact="compact">
<dt> <code>EINVAL</code></dt>
<dd><p>The <var>signum</var> argument is not valid, or you are trying to
trap or ignore <code>SIGKILL</code> or <code>SIGSTOP</code>.
</p></dd>
</dl>
</dd></dl>
<hr size="6">
<a name="Signal-and-Sigaction"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Advanced-Signal-Handling" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Sigaction-Function-Example" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Actions" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Interaction-of-signal-and-sigaction"></a>
<h3 class="subsection">24.3.3 Interaction of <code>signal</code> and <code>sigaction</code></h3>
<p>It’s possible to use both the <code>signal</code> and <code>sigaction</code>
functions within a single program, but you have to be careful because
they can interact in slightly strange ways.
</p>
<p>The <code>sigaction</code> function specifies more information than the
<code>signal</code> function, so the return value from <code>signal</code> cannot
express the full range of <code>sigaction</code> possibilities. Therefore, if
you use <code>signal</code> to save and later reestablish an action, it may
not be able to reestablish properly a handler that was established with
<code>sigaction</code>.
</p>
<p>To avoid having problems as a result, always use <code>sigaction</code> to
save and restore a handler if your program uses <code>sigaction</code> at all.
Since <code>sigaction</code> is more general, it can properly save and
reestablish any action, regardless of whether it was established
originally with <code>signal</code> or <code>sigaction</code>.
</p>
<p>On some systems if you establish an action with <code>signal</code> and then
examine it with <code>sigaction</code>, the handler address that you get may
not be the same as what you specified with <code>signal</code>. It may not
even be suitable for use as an action argument with <code>signal</code>. But
you can rely on using it as an argument to <code>sigaction</code>. This
problem never happens on the GNU system.
</p>
<p>So, you’re better off using one or the other of the mechanisms
consistently within a single program.
</p>
<p><strong>Portability Note:</strong> The basic <code>signal</code> function is a feature
of ISO C, while <code>sigaction</code> is part of the POSIX.1 standard. If
you are concerned about portability to non-POSIX systems, then you
should use the <code>signal</code> function instead.
</p>
<hr size="6">
<a name="Sigaction-Function-Example"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Signal-and-Sigaction" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Flags-for-Sigaction" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Actions" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="sigaction-Function-Example"></a>
<h3 class="subsection">24.3.4 <code>sigaction</code> Function Example</h3>
<p>In <a href="#Basic-Signal-Handling">Basic Signal Handling</a>, we gave an example of establishing a
simple handler for termination signals using <code>signal</code>. Here is an
equivalent example using <code>sigaction</code>:
</p>
<table><tr><td> </td><td><pre class="smallexample">#include <signal.h>
void
termination_handler (int signum)
{
struct temp_file *p;
for (p = temp_file_list; p; p = p->next)
unlink (p->name);
}
int
main (void)
{
…
struct sigaction new_action, old_action;
/* <span class="roman">Set up the structure to specify the new action.</span> */
new_action.sa_handler = termination_handler;
sigemptyset (&new_action.sa_mask);
new_action.sa_flags = 0;
sigaction (SIGINT, NULL, &old_action);
if (old_action.sa_handler != SIG_IGN)
sigaction (SIGINT, &new_action, NULL);
sigaction (SIGHUP, NULL, &old_action);
if (old_action.sa_handler != SIG_IGN)
sigaction (SIGHUP, &new_action, NULL);
sigaction (SIGTERM, NULL, &old_action);
if (old_action.sa_handler != SIG_IGN)
sigaction (SIGTERM, &new_action, NULL);
…
}
</pre></td></tr></table>
<p>The program just loads the <code>new_action</code> structure with the desired
parameters and passes it in the <code>sigaction</code> call. The usage of
<code>sigemptyset</code> is described later; see <a href="#Blocking-Signals">Blocking Signals</a>.
</p>
<p>As in the example using <code>signal</code>, we avoid handling signals
previously set to be ignored. Here we can avoid altering the signal
handler even momentarily, by using the feature of <code>sigaction</code> that
lets us examine the current action without specifying a new one.
</p>
<p>Here is another example. It retrieves information about the current
action for <code>SIGINT</code> without changing that action.
</p>
<table><tr><td> </td><td><pre class="smallexample">struct sigaction query_action;
if (sigaction (SIGINT, NULL, &query_action) < 0)
/* <span class="roman"><code>sigaction</code> returns -1 in case of error.</span> */
else if (query_action.sa_handler == SIG_DFL)
/* <span class="roman"><code>SIGINT</code> is handled in the default, fatal manner.</span> */
else if (query_action.sa_handler == SIG_IGN)
/* <span class="roman"><code>SIGINT</code> is ignored.</span> */
else
/* <span class="roman">A programmer-defined signal handler is in effect.</span> */
</pre></td></tr></table>
<hr size="6">
<a name="Flags-for-Sigaction"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Sigaction-Function-Example" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Initial-Signal-Actions" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Actions" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Flags-for-sigaction"></a>
<h3 class="subsection">24.3.5 Flags for <code>sigaction</code></h3>
<a name="index-signal-flags"></a>
<a name="index-flags-for-sigaction"></a>
<a name="index-sigaction-flags"></a>
<p>The <code>sa_flags</code> member of the <code>sigaction</code> structure is a
catch-all for special features. Most of the time, <code>SA_RESTART</code> is
a good value to use for this field.
</p>
<p>The value of <code>sa_flags</code> is interpreted as a bit mask. Thus, you
should choose the flags you want to set, <small>OR</small> those flags together,
and store the result in the <code>sa_flags</code> member of your
<code>sigaction</code> structure.
</p>
<p>Each signal number has its own set of flags. Each call to
<code>sigaction</code> affects one particular signal number, and the flags
that you specify apply only to that particular signal.
</p>
<p>In the GNU C library, establishing a handler with <code>signal</code> sets all
the flags to zero except for <code>SA_RESTART</code>, whose value depends on
the settings you have made with <code>siginterrupt</code>. See section <a href="#Interrupted-Primitives">Primitives Interrupted by Signals</a>, to see what this is about.
</p>
<a name="index-signal_002eh-4"></a>
<p>These macros are defined in the header file ‘<tt>signal.h</tt>’.
</p>
<dl>
<dt><a name="index-SA_005fNOCLDSTOP"></a><u>Macro:</u> int <b>SA_NOCLDSTOP</b></dt>
<dd><p>This flag is meaningful only for the <code>SIGCHLD</code> signal. When the
flag is set, the system delivers the signal for a terminated child
process but not for one that is stopped. By default, <code>SIGCHLD</code> is
delivered for both terminated children and stopped children.
</p>
<p>Setting this flag for a signal other than <code>SIGCHLD</code> has no effect.
</p></dd></dl>
<dl>
<dt><a name="index-SA_005fONSTACK"></a><u>Macro:</u> int <b>SA_ONSTACK</b></dt>
<dd><p>If this flag is set for a particular signal number, the system uses the
signal stack when delivering that kind of signal. See section <a href="#Signal-Stack">Using a Separate Signal Stack</a>.
If a signal with this flag arrives and you have not set a signal stack,
the system terminates the program with <code>SIGILL</code>.
</p></dd></dl>
<dl>
<dt><a name="index-SA_005fRESTART"></a><u>Macro:</u> int <b>SA_RESTART</b></dt>
<dd><p>This flag controls what happens when a signal is delivered during
certain primitives (such as <code>open</code>, <code>read</code> or <code>write</code>),
and the signal handler returns normally. There are two alternatives:
the library function can resume, or it can return failure with error
code <code>EINTR</code>.
</p>
<p>The choice is controlled by the <code>SA_RESTART</code> flag for the
particular kind of signal that was delivered. If the flag is set,
returning from a handler resumes the library function. If the flag is
clear, returning from a handler makes the function fail.
See section <a href="#Interrupted-Primitives">Primitives Interrupted by Signals</a>.
</p></dd></dl>
<hr size="6">
<a name="Initial-Signal-Actions"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Flags-for-Sigaction" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Defining-Handlers" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Actions" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Initial-Signal-Actions-1"></a>
<h3 class="subsection">24.3.6 Initial Signal Actions</h3>
<a name="index-initial-signal-actions"></a>
<p>When a new process is created (see section <a href="libc_26.html#Creating-a-Process">Creating a Process</a>), it inherits
handling of signals from its parent process. However, when you load a
new process image using the <code>exec</code> function (see section <a href="libc_26.html#Executing-a-File">Executing a File</a>), any signals that you’ve defined your own handlers for revert to
their <code>SIG_DFL</code> handling. (If you think about it a little, this
makes sense; the handler functions from the old program are specific to
that program, and aren’t even present in the address space of the new
program image.) Of course, the new program can establish its own
handlers.
</p>
<p>When a program is run by a shell, the shell normally sets the initial
actions for the child process to <code>SIG_DFL</code> or <code>SIG_IGN</code>, as
appropriate. It’s a good idea to check to make sure that the shell has
not set up an initial action of <code>SIG_IGN</code> before you establish your
own signal handlers.
</p>
<p>Here is an example of how to establish a handler for <code>SIGHUP</code>, but
not if <code>SIGHUP</code> is currently ignored:
</p>
<table><tr><td> </td><td><pre class="smallexample">…
struct sigaction temp;
sigaction (SIGHUP, NULL, &temp);
if (temp.sa_handler != SIG_IGN)
{
temp.sa_handler = handle_sighup;
sigemptyset (&temp.sa_mask);
sigaction (SIGHUP, &temp, NULL);
}
</pre></td></tr></table>
<hr size="6">
<a name="Defining-Handlers"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Initial-Signal-Actions" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Handler-Returns" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Defining-Signal-Handlers"></a>
<h2 class="section">24.4 Defining Signal Handlers</h2>
<a name="index-signal-handler-function"></a>
<p>This section describes how to write a signal handler function that can
be established with the <code>signal</code> or <code>sigaction</code> functions.
</p>
<p>A signal handler is just a function that you compile together with the
rest of the program. Instead of directly invoking the function, you use
<code>signal</code> or <code>sigaction</code> to tell the operating system to call
it when a signal arrives. This is known as <em>establishing</em> the
handler. See section <a href="#Signal-Actions">Specifying Signal Actions</a>.
</p>
<p>There are two basic strategies you can use in signal handler functions:
</p>
<ul>
<li>
You can have the handler function note that the signal arrived by
tweaking some global data structures, and then return normally.
</li><li>
You can have the handler function terminate the program or transfer
control to a point where it can recover from the situation that caused
the signal.
</li></ul>
<p>You need to take special care in writing handler functions because they
can be called asynchronously. That is, a handler might be called at any
point in the program, unpredictably. If two signals arrive during a
very short interval, one handler can run within another. This section
describes what your handler should do, and what you should avoid.
</p>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#Handler-Returns">24.4.1 Signal Handlers that Return</a></td><td> </td><td align="left" valign="top"> Handlers that return normally, and what
this means.
</td></tr>
<tr><td align="left" valign="top"><a href="#Termination-in-Handler">24.4.2 Handlers That Terminate the Process</a></td><td> </td><td align="left" valign="top"> How handler functions terminate a program.
</td></tr>
<tr><td align="left" valign="top"><a href="#Longjmp-in-Handler">24.4.3 Nonlocal Control Transfer in Handlers</a></td><td> </td><td align="left" valign="top"> Nonlocal transfer of control out of a
signal handler.
</td></tr>
<tr><td align="left" valign="top"><a href="#Signals-in-Handler">24.4.4 Signals Arriving While a Handler Runs</a></td><td> </td><td align="left" valign="top"> What happens when signals arrive while
the handler is already occupied.
</td></tr>
<tr><td align="left" valign="top"><a href="#Merged-Signals">24.4.5 Signals Close Together Merge into One</a></td><td> </td><td align="left" valign="top"> When a second signal arrives before the
first is handled.
</td></tr>
<tr><td align="left" valign="top"><a href="#Nonreentrancy">24.4.6 Signal Handling and Nonreentrant Functions</a></td><td> </td><td align="left" valign="top"> Do not call any functions unless you know they
are reentrant with respect to signals.
</td></tr>
<tr><td align="left" valign="top"><a href="#Atomic-Data-Access">24.4.7 Atomic Data Access and Signal Handling</a></td><td> </td><td align="left" valign="top"> A single handler can run in the middle of
reading or writing a single object.
</td></tr>
</table>
<hr size="6">
<a name="Handler-Returns"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Defining-Handlers" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Termination-in-Handler" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Defining-Handlers" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Signal-Handlers-that-Return"></a>
<h3 class="subsection">24.4.1 Signal Handlers that Return</h3>
<p>Handlers which return normally are usually used for signals such as
<code>SIGALRM</code> and the I/O and interprocess communication signals. But
a handler for <code>SIGINT</code> might also return normally after setting a
flag that tells the program to exit at a convenient time.
</p>
<p>It is not safe to return normally from the handler for a program error
signal, because the behavior of the program when the handler function
returns is not defined after a program error. See section <a href="#Program-Error-Signals">Program Error Signals</a>.
</p>
<p>Handlers that return normally must modify some global variable in order
to have any effect. Typically, the variable is one that is examined
periodically by the program during normal operation. Its data type
should be <code>sig_atomic_t</code> for reasons described in <a href="#Atomic-Data-Access">Atomic Data Access and Signal Handling</a>.
</p>
<p>Here is a simple example of such a program. It executes the body of
the loop until it has noticed that a <code>SIGALRM</code> signal has arrived.
This technique is useful because it allows the iteration in progress
when the signal arrives to complete before the loop exits.
</p>
<table><tr><td> </td><td><pre class="smallexample">#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
/* <span class="roman">This flag controls termination of the main loop.</span> */
volatile sig_atomic_t keep_going = 1;
/* <span class="roman">The signal handler just clears the flag and re-enables itself.</span> */
void
catch_alarm (int sig)
{
keep_going = 0;
signal (sig, catch_alarm);
}
void
do_stuff (void)
{
puts ("Doing stuff while waiting for alarm....");
}
int
main (void)
{
/* <span class="roman">Establish a handler for SIGALRM signals.</span> */
signal (SIGALRM, catch_alarm);
/* <span class="roman">Set an alarm to go off in a little while.</span> */
alarm (2);
/* <span class="roman">Check the flag once in a while to see when to quit.</span> */
while (keep_going)
do_stuff ();
return EXIT_SUCCESS;
}
</pre></td></tr></table>
<hr size="6">
<a name="Termination-in-Handler"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Handler-Returns" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Longjmp-in-Handler" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Defining-Handlers" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Handlers-That-Terminate-the-Process"></a>
<h3 class="subsection">24.4.2 Handlers That Terminate the Process</h3>
<p>Handler functions that terminate the program are typically used to cause
orderly cleanup or recovery from program error signals and interactive
interrupts.
</p>
<p>The cleanest way for a handler to terminate the process is to raise the
same signal that ran the handler in the first place. Here is how to do
this:
</p>
<table><tr><td> </td><td><pre class="smallexample">volatile sig_atomic_t fatal_error_in_progress = 0;
void
fatal_error_signal (int sig)
{
</pre><pre class="smallexample"> /* <span class="roman">Since this handler is established for more than one kind of signal, </span>
<span class="roman">it might still get invoked recursively by delivery of some other kind</span>
<span class="roman">of signal. Use a static variable to keep track of that.</span> */
if (fatal_error_in_progress)
raise (sig);
fatal_error_in_progress = 1;
</pre><pre class="smallexample">
</pre><pre class="smallexample"> /* <span class="roman">Now do the clean up actions:</span>
<span class="roman">- reset terminal modes</span>
<span class="roman">- kill child processes</span>
<span class="roman">- remove lock files</span> */
…
</pre><pre class="smallexample">
</pre><pre class="smallexample"> /* <span class="roman">Now reraise the signal. We reactivate the signal's</span>
<span class="roman">default handling, which is to terminate the process.</span>
<span class="roman">We could just call <code>exit</code> or <code>abort</code>,</span>
<span class="roman">but reraising the signal sets the return status</span>
<span class="roman">from the process correctly.</span> */
signal (sig, SIG_DFL);
raise (sig);
}
</pre></td></tr></table>
<hr size="6">
<a name="Longjmp-in-Handler"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Termination-in-Handler" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Signals-in-Handler" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Defining-Handlers" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Nonlocal-Control-Transfer-in-Handlers"></a>
<h3 class="subsection">24.4.3 Nonlocal Control Transfer in Handlers</h3>
<a name="index-non_002dlocal-exit_002c-from-signal-handler"></a>
<p>You can do a nonlocal transfer of control out of a signal handler using
the <code>setjmp</code> and <code>longjmp</code> facilities (see section <a href="libc_23.html#Non_002dLocal-Exits">Non-Local Exits</a>).
</p>
<p>When the handler does a nonlocal control transfer, the part of the
program that was running will not continue. If this part of the program
was in the middle of updating an important data structure, the data
structure will remain inconsistent. Since the program does not
terminate, the inconsistency is likely to be noticed later on.
</p>
<p>There are two ways to avoid this problem. One is to block the signal
for the parts of the program that update important data structures.
Blocking the signal delays its delivery until it is unblocked, once the
critical updating is finished. See section <a href="#Blocking-Signals">Blocking Signals</a>.
</p>
<p>The other way is to re-initialize the crucial data structures in the
signal handler, or to make their values consistent.
</p>
<p>Here is a rather schematic example showing the reinitialization of one
global variable.
</p>
<table><tr><td> </td><td><pre class="smallexample">#include <signal.h>
#include <setjmp.h>
jmp_buf return_to_top_level;
volatile sig_atomic_t waiting_for_input;
void
handle_sigint (int signum)
{
/* <span class="roman">We may have been waiting for input when the signal arrived,</span>
<span class="roman">but we are no longer waiting once we transfer control.</span> */
waiting_for_input = 0;
longjmp (return_to_top_level, 1);
}
</pre><pre class="smallexample">
</pre><pre class="smallexample">int
main (void)
{
…
signal (SIGINT, sigint_handler);
…
while (1) {
prepare_for_command ();
if (setjmp (return_to_top_level) == 0)
read_and_execute_command ();
}
}
</pre><pre class="smallexample">
</pre><pre class="smallexample">/* <span class="roman">Imagine this is a subroutine used by various commands.</span> */
char *
read_data ()
{
if (input_from_terminal) {
waiting_for_input = 1;
…
waiting_for_input = 0;
} else {
…
}
}
</pre></td></tr></table>
<hr size="6">
<a name="Signals-in-Handler"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Longjmp-in-Handler" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Merged-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Defining-Handlers" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Signals-Arriving-While-a-Handler-Runs"></a>
<h3 class="subsection">24.4.4 Signals Arriving While a Handler Runs</h3>
<a name="index-race-conditions_002c-relating-to-signals"></a>
<p>What happens if another signal arrives while your signal handler
function is running?
</p>
<p>When the handler for a particular signal is invoked, that signal is
automatically blocked until the handler returns. That means that if two
signals of the same kind arrive close together, the second one will be
held until the first has been handled. (The handler can explicitly
unblock the signal using <code>sigprocmask</code>, if you want to allow more
signals of this type to arrive; see <a href="#Process-Signal-Mask">Process Signal Mask</a>.)
</p>
<p>However, your handler can still be interrupted by delivery of another
kind of signal. To avoid this, you can use the <code>sa_mask</code> member of
the action structure passed to <code>sigaction</code> to explicitly specify
which signals should be blocked while the signal handler runs. These
signals are in addition to the signal for which the handler was invoked,
and any other signals that are normally blocked by the process.
See section <a href="#Blocking-for-Handler">Blocking Signals for a Handler</a>.
</p>
<p>When the handler returns, the set of blocked signals is restored to the
value it had before the handler ran. So using <code>sigprocmask</code> inside
the handler only affects what signals can arrive during the execution of
the handler itself, not what signals can arrive once the handler returns.
</p>
<p><strong>Portability Note:</strong> Always use <code>sigaction</code> to establish a
handler for a signal that you expect to receive asynchronously, if you
want your program to work properly on System V Unix. On this system,
the handling of a signal whose handler was established with
<code>signal</code> automatically sets the signal’s action back to
<code>SIG_DFL</code>, and the handler must re-establish itself each time it
runs. This practice, while inconvenient, does work when signals cannot
arrive in succession. However, if another signal can arrive right away,
it may arrive before the handler can re-establish itself. Then the
second signal would receive the default handling, which could terminate
the process.
</p>
<hr size="6">
<a name="Merged-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Signals-in-Handler" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Nonreentrancy" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Defining-Handlers" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Signals-Close-Together-Merge-into-One"></a>
<h3 class="subsection">24.4.5 Signals Close Together Merge into One</h3>
<a name="index-handling-multiple-signals"></a>
<a name="index-successive-signals"></a>
<a name="index-merging-of-signals"></a>
<p>If multiple signals of the same type are delivered to your process
before your signal handler has a chance to be invoked at all, the
handler may only be invoked once, as if only a single signal had
arrived. In effect, the signals merge into one. This situation can
arise when the signal is blocked, or in a multiprocessing environment
where the system is busy running some other processes while the signals
are delivered. This means, for example, that you cannot reliably use a
signal handler to count signals. The only distinction you can reliably
make is whether at least one signal has arrived since a given time in
the past.
</p>
<p>Here is an example of a handler for <code>SIGCHLD</code> that compensates for
the fact that the number of signals received may not equal the number of
child processes that generate them. It assumes that the program keeps track
of all the child processes with a chain of structures as follows:
</p>
<table><tr><td> </td><td><pre class="smallexample">struct process
{
struct process *next;
/* <span class="roman">The process ID of this child.</span> */
int pid;
/* <span class="roman">The descriptor of the pipe or pseudo terminal</span>
<span class="roman">on which output comes from this child.</span> */
int input_descriptor;
/* <span class="roman">Nonzero if this process has stopped or terminated.</span> */
sig_atomic_t have_status;
/* <span class="roman">The status of this child; 0 if running,</span>
<span class="roman">otherwise a status value from <code>waitpid</code>.</span> */
int status;
};
struct process *process_list;
</pre></td></tr></table>
<p>This example also uses a flag to indicate whether signals have arrived
since some time in the past—whenever the program last cleared it to
zero.
</p>
<table><tr><td> </td><td><pre class="smallexample">/* <span class="roman">Nonzero means some child's status has changed</span>
<span class="roman">so look at <code>process_list</code> for the details.</span> */
int process_status_change;
</pre></td></tr></table>
<p>Here is the handler itself:
</p>
<table><tr><td> </td><td><pre class="smallexample">void
sigchld_handler (int signo)
{
int old_errno = errno;
while (1) {
register int pid;
int w;
struct process *p;
/* <span class="roman">Keep asking for a status until we get a definitive result.</span> */
do
{
errno = 0;
pid = waitpid (WAIT_ANY, &w, WNOHANG | WUNTRACED);
}
while (pid <= 0 && errno == EINTR);
if (pid <= 0) {
/* <span class="roman">A real failure means there are no more</span>
<span class="roman">stopped or terminated child processes, so return.</span> */
errno = old_errno;
return;
}
/* <span class="roman">Find the process that signaled us, and record its status.</span> */
for (p = process_list; p; p = p->next)
if (p->pid == pid) {
p->status = w;
/* <span class="roman">Indicate that the <code>status</code> field</span>
<span class="roman">has data to look at. We do this only after storing it.</span> */
p->have_status = 1;
/* <span class="roman">If process has terminated, stop waiting for its output.</span> */
if (WIFSIGNALED (w) || WIFEXITED (w))
if (p->input_descriptor)
FD_CLR (p->input_descriptor, &input_wait_mask);
/* <span class="roman">The program should check this flag from time to time</span>
<span class="roman">to see if there is any news in <code>process_list</code>.</span> */
++process_status_change;
}
/* <span class="roman">Loop around to handle all the processes</span>
<span class="roman">that have something to tell us.</span> */
}
}
</pre></td></tr></table>
<p>Here is the proper way to check the flag <code>process_status_change</code>:
</p>
<table><tr><td> </td><td><pre class="smallexample">if (process_status_change) {
struct process *p;
process_status_change = 0;
for (p = process_list; p; p = p->next)
if (p->have_status) {
… <span class="roman">Examine <code>p->status</code></span> …
}
}
</pre></td></tr></table>
<p>It is vital to clear the flag before examining the list; otherwise, if a
signal were delivered just before the clearing of the flag, and after
the appropriate element of the process list had been checked, the status
change would go unnoticed until the next signal arrived to set the flag
again. You could, of course, avoid this problem by blocking the signal
while scanning the list, but it is much more elegant to guarantee
correctness by doing things in the right order.
</p>
<p>The loop which checks process status avoids examining <code>p->status</code>
until it sees that status has been validly stored. This is to make sure
that the status cannot change in the middle of accessing it. Once
<code>p->have_status</code> is set, it means that the child process is stopped
or terminated, and in either case, it cannot stop or terminate again
until the program has taken notice. See section <a href="#Atomic-Usage">Atomic Usage Patterns</a>, for more
information about coping with interruptions during accesses of a
variable.
</p>
<p>Here is another way you can test whether the handler has run since the
last time you checked. This technique uses a counter which is never
changed outside the handler. Instead of clearing the count, the program
remembers the previous value and sees whether it has changed since the
previous check. The advantage of this method is that different parts of
the program can check independently, each part checking whether there
has been a signal since that part last checked.
</p>
<table><tr><td> </td><td><pre class="smallexample">sig_atomic_t process_status_change;
sig_atomic_t last_process_status_change;
…
{
sig_atomic_t prev = last_process_status_change;
last_process_status_change = process_status_change;
if (last_process_status_change != prev) {
struct process *p;
for (p = process_list; p; p = p->next)
if (p->have_status) {
… <span class="roman">Examine <code>p->status</code></span> …
}
}
}
</pre></td></tr></table>
<hr size="6">
<a name="Nonreentrancy"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Merged-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Atomic-Data-Access" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Defining-Handlers" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Signal-Handling-and-Nonreentrant-Functions"></a>
<h3 class="subsection">24.4.6 Signal Handling and Nonreentrant Functions</h3>
<a name="index-restrictions-on-signal-handler-functions"></a>
<p>Handler functions usually don’t do very much. The best practice is to
write a handler that does nothing but set an external variable that the
program checks regularly, and leave all serious work to the program.
This is best because the handler can be called asynchronously, at
unpredictable times—perhaps in the middle of a primitive function, or
even between the beginning and the end of a C operator that requires
multiple instructions. The data structures being manipulated might
therefore be in an inconsistent state when the handler function is
invoked. Even copying one <code>int</code> variable into another can take two
instructions on most machines.
</p>
<p>This means you have to be very careful about what you do in a signal
handler.
</p>
<ul>
<li>
<a name="index-volatile-declarations"></a>
If your handler needs to access any global variables from your program,
declare those variables <code>volatile</code>. This tells the compiler that
the value of the variable might change asynchronously, and inhibits
certain optimizations that would be invalidated by such modifications.
</li><li>
<a name="index-reentrant-functions"></a>
If you call a function in the handler, make sure it is <em>reentrant</em>
with respect to signals, or else make sure that the signal cannot
interrupt a call to a related function.
</li></ul>
<p>A function can be non-reentrant if it uses memory that is not on the
stack.
</p>
<ul>
<li>
If a function uses a static variable or a global variable, or a
dynamically-allocated object that it finds for itself, then it is
non-reentrant and any two calls to the function can interfere.
<p>For example, suppose that the signal handler uses <code>gethostbyname</code>.
This function returns its value in a static object, reusing the same
object each time. If the signal happens to arrive during a call to
<code>gethostbyname</code>, or even after one (while the program is still
using the value), it will clobber the value that the program asked for.
</p>
<p>However, if the program does not use <code>gethostbyname</code> or any other
function that returns information in the same object, or if it always
blocks signals around each use, then you are safe.
</p>
<p>There are a large number of library functions that return values in a
fixed object, always reusing the same object in this fashion, and all of
them cause the same problem. Function descriptions in this manual
always mention this behavior.
</p>
</li><li>
If a function uses and modifies an object that you supply, then it is
potentially non-reentrant; two calls can interfere if they use the same
object.
<p>This case arises when you do I/O using streams. Suppose that the
signal handler prints a message with <code>fprintf</code>. Suppose that the
program was in the middle of an <code>fprintf</code> call using the same
stream when the signal was delivered. Both the signal handler’s message
and the program’s data could be corrupted, because both calls operate on
the same data structure—the stream itself.
</p>
<p>However, if you know that the stream that the handler uses cannot
possibly be used by the program at a time when signals can arrive, then
you are safe. It is no problem if the program uses some other stream.
</p>
</li><li>
On most systems, <code>malloc</code> and <code>free</code> are not reentrant,
because they use a static data structure which records what memory
blocks are free. As a result, no library functions that allocate or
free memory are reentrant. This includes functions that allocate space
to store a result.
<p>The best way to avoid the need to allocate memory in a handler is to
allocate in advance space for signal handlers to use.
</p>
<p>The best way to avoid freeing memory in a handler is to flag or record
the objects to be freed, and have the program check from time to time
whether anything is waiting to be freed. But this must be done with
care, because placing an object on a chain is not atomic, and if it is
interrupted by another signal handler that does the same thing, you
could “lose” one of the objects.
</p>
</li><li>
Any function that modifies <code>errno</code> is non-reentrant, but you can
correct for this: in the handler, save the original value of
<code>errno</code> and restore it before returning normally. This prevents
errors that occur within the signal handler from being confused with
errors from system calls at the point the program is interrupted to run
the handler.
<p>This technique is generally applicable; if you want to call in a handler
a function that modifies a particular object in memory, you can make
this safe by saving and restoring that object.
</p>
</li><li>
Merely reading from a memory object is safe provided that you can deal
with any of the values that might appear in the object at a time when
the signal can be delivered. Keep in mind that assignment to some data
types requires more than one instruction, which means that the handler
could run “in the middle of” an assignment to the variable if its type
is not atomic. See section <a href="#Atomic-Data-Access">Atomic Data Access and Signal Handling</a>.
</li><li>
Merely writing into a memory object is safe as long as a sudden change
in the value, at any time when the handler might run, will not disturb
anything.
</li></ul>
<hr size="6">
<a name="Atomic-Data-Access"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Nonreentrancy" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Non_002datomic-Example" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Defining-Handlers" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Atomic-Data-Access-and-Signal-Handling"></a>
<h3 class="subsection">24.4.7 Atomic Data Access and Signal Handling</h3>
<p>Whether the data in your application concerns atoms, or mere text, you
have to be careful about the fact that access to a single datum is not
necessarily <em>atomic</em>. This means that it can take more than one
instruction to read or write a single object. In such cases, a signal
handler might be invoked in the middle of reading or writing the object.
</p>
<p>There are three ways you can cope with this problem. You can use data
types that are always accessed atomically; you can carefully arrange
that nothing untoward happens if an access is interrupted, or you can
block all signals around any access that had better not be interrupted
(see section <a href="#Blocking-Signals">Blocking Signals</a>).
</p>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#Non_002datomic-Example">24.4.7.1 Problems with Non-Atomic Access</a></td><td> </td><td align="left" valign="top"> A program illustrating interrupted access.
</td></tr>
<tr><td align="left" valign="top"><a href="#Atomic-Types">24.4.7.2 Atomic Types</a></td><td> </td><td align="left" valign="top"> Data types that guarantee no interruption.
</td></tr>
<tr><td align="left" valign="top"><a href="#Atomic-Usage">24.4.7.3 Atomic Usage Patterns</a></td><td> </td><td align="left" valign="top"> Proving that interruption is harmless.
</td></tr>
</table>
<hr size="6">
<a name="Non_002datomic-Example"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Atomic-Data-Access" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Atomic-Types" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Atomic-Data-Access" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Problems-with-Non_002dAtomic-Access"></a>
<h4 class="subsubsection">24.4.7.1 Problems with Non-Atomic Access</h4>
<p>Here is an example which shows what can happen if a signal handler runs
in the middle of modifying a variable. (Interrupting the reading of a
variable can also lead to paradoxical results, but here we only show
writing.)
</p>
<table><tr><td> </td><td><pre class="smallexample">#include <signal.h>
#include <stdio.h>
volatile struct two_words { int a, b; } memory;
void
handler(int signum)
{
printf ("%d,%d\n", memory.a, memory.b);
alarm (1);
}
</pre><pre class="smallexample">int
main (void)
{
static struct two_words zeros = { 0, 0 }, ones = { 1, 1 };
signal (SIGALRM, handler);
memory = zeros;
alarm (1);
while (1)
{
memory = zeros;
memory = ones;
}
}
</pre></td></tr></table>
<p>This program fills <code>memory</code> with zeros, ones, zeros, ones,
alternating forever; meanwhile, once per second, the alarm signal handler
prints the current contents. (Calling <code>printf</code> in the handler is
safe in this program because it is certainly not being called outside
the handler when the signal happens.)
</p>
<p>Clearly, this program can print a pair of zeros or a pair of ones. But
that’s not all it can do! On most machines, it takes several
instructions to store a new value in <code>memory</code>, and the value is
stored one word at a time. If the signal is delivered in between these
instructions, the handler might find that <code>memory.a</code> is zero and
<code>memory.b</code> is one (or vice versa).
</p>
<p>On some machines it may be possible to store a new value in
<code>memory</code> with just one instruction that cannot be interrupted. On
these machines, the handler will always print two zeros or two ones.
</p>
<hr size="6">
<a name="Atomic-Types"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Non_002datomic-Example" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Atomic-Usage" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Atomic-Data-Access" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Atomic-Types-1"></a>
<h4 class="subsubsection">24.4.7.2 Atomic Types</h4>
<p>To avoid uncertainty about interrupting access to a variable, you can
use a particular data type for which access is always atomic:
<code>sig_atomic_t</code>. Reading and writing this data type is guaranteed
to happen in a single instruction, so there’s no way for a handler to
run “in the middle” of an access.
</p>
<p>The type <code>sig_atomic_t</code> is always an integer data type, but which
one it is, and how many bits it contains, may vary from machine to
machine.
</p>
<dl>
<dt><a name="index-sig_005fatomic_005ft"></a><u>Data Type:</u> <b>sig_atomic_t</b></dt>
<dd><p>This is an integer data type. Objects of this type are always accessed
atomically.
</p></dd></dl>
<p>In practice, you can assume that <code>int</code> is atomic.
You can also assume that pointer
types are atomic; that is very convenient. Both of these assumptions
are true on all of the machines that the GNU C library supports and on
all POSIX systems we know of.
</p>
<hr size="6">
<a name="Atomic-Usage"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Atomic-Types" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Interrupted-Primitives" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Atomic-Data-Access" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Atomic-Usage-Patterns"></a>
<h4 class="subsubsection">24.4.7.3 Atomic Usage Patterns</h4>
<p>Certain patterns of access avoid any problem even if an access is
interrupted. For example, a flag which is set by the handler, and
tested and cleared by the main program from time to time, is always safe
even if access actually requires two instructions. To show that this is
so, we must consider each access that could be interrupted, and show
that there is no problem if it is interrupted.
</p>
<p>An interrupt in the middle of testing the flag is safe because either it’s
recognized to be nonzero, in which case the precise value doesn’t
matter, or it will be seen to be nonzero the next time it’s tested.
</p>
<p>An interrupt in the middle of clearing the flag is no problem because
either the value ends up zero, which is what happens if a signal comes
in just before the flag is cleared, or the value ends up nonzero, and
subsequent events occur as if the signal had come in just after the flag
was cleared. As long as the code handles both of these cases properly,
it can also handle a signal in the middle of clearing the flag. (This
is an example of the sort of reasoning you need to do to figure out
whether non-atomic usage is safe.)
</p>
<p>Sometimes you can insure uninterrupted access to one object by
protecting its use with another object, perhaps one whose type
guarantees atomicity. See section <a href="#Merged-Signals">Signals Close Together Merge into One</a>, for an example.
</p>
<hr size="6">
<a name="Interrupted-Primitives"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Atomic-Usage" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Generating-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Primitives-Interrupted-by-Signals"></a>
<h2 class="section">24.5 Primitives Interrupted by Signals</h2>
<p>A signal can arrive and be handled while an I/O primitive such as
<code>open</code> or <code>read</code> is waiting for an I/O device. If the signal
handler returns, the system faces the question: what should happen next?
</p>
<p>POSIX specifies one approach: make the primitive fail right away. The
error code for this kind of failure is <code>EINTR</code>. This is flexible,
but usually inconvenient. Typically, POSIX applications that use signal
handlers must check for <code>EINTR</code> after each library function that
can return it, in order to try the call again. Often programmers forget
to check, which is a common source of error.
</p>
<p>The GNU library provides a convenient way to retry a call after a
temporary failure, with the macro <code>TEMP_FAILURE_RETRY</code>:
</p>
<dl>
<dt><a name="index-TEMP_005fFAILURE_005fRETRY"></a><u>Macro:</u> <b>TEMP_FAILURE_RETRY</b><i> (<var>expression</var>)</i></dt>
<dd><p>This macro evaluates <var>expression</var> once, and examines its value as
type <code>long int</code>. If the value equals <code>-1</code>, that indicates a
failure and <code>errno</code> should be set to show what kind of failure.
If it fails and reports error code <code>EINTR</code>,
<code>TEMP_FAILURE_RETRY</code> evaluates it again, and over and over until
the result is not a temporary failure.
</p>
<p>The value returned by <code>TEMP_FAILURE_RETRY</code> is whatever value
<var>expression</var> produced.
</p></dd></dl>
<p>BSD avoids <code>EINTR</code> entirely and provides a more convenient
approach: to restart the interrupted primitive, instead of making it
fail. If you choose this approach, you need not be concerned with
<code>EINTR</code>.
</p>
<p>You can choose either approach with the GNU library. If you use
<code>sigaction</code> to establish a signal handler, you can specify how that
handler should behave. If you specify the <code>SA_RESTART</code> flag,
return from that handler will resume a primitive; otherwise, return from
that handler will cause <code>EINTR</code>. See section <a href="#Flags-for-Sigaction">Flags for <code>sigaction</code></a>.
</p>
<p>Another way to specify the choice is with the <code>siginterrupt</code>
function. See section <a href="#BSD-Handler">BSD Function to Establish a Handler</a>.
</p>
<p>When you don’t specify with <code>sigaction</code> or <code>siginterrupt</code> what
a particular handler should do, it uses a default choice. The default
choice in the GNU library depends on the feature test macros you have
defined. If you define <code>_BSD_SOURCE</code> or <code>_GNU_SOURCE</code> before
calling <code>signal</code>, the default is to resume primitives; otherwise,
the default is to make them fail with <code>EINTR</code>. (The library
contains alternate versions of the <code>signal</code> function, and the
feature test macros determine which one you really call.) See section <a href="libc_1.html#Feature-Test-Macros">Feature Test Macros</a>.
<a name="index-EINTR_002c-and-restarting-interrupted-primitives"></a>
<a name="index-restarting-interrupted-primitives"></a>
<a name="index-interrupting-primitives"></a>
<a name="index-primitives_002c-interrupting"></a>
</p>
<p>The description of each primitive affected by this issue
lists <code>EINTR</code> among the error codes it can return.
</p>
<p>There is one situation where resumption never happens no matter which
choice you make: when a data-transfer function such as <code>read</code> or
<code>write</code> is interrupted by a signal after transferring part of the
data. In this case, the function returns the number of bytes already
transferred, indicating partial success.
</p>
<p>This might at first appear to cause unreliable behavior on
record-oriented devices (including datagram sockets; see section <a href="libc_16.html#Datagrams">Datagram Socket Operations</a>),
where splitting one <code>read</code> or <code>write</code> into two would read or
write two records. Actually, there is no problem, because interruption
after a partial transfer cannot happen on such devices; they always
transfer an entire record in one burst, with no waiting once data
transfer has started.
</p>
<hr size="6">
<a name="Generating-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Interrupted-Primitives" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Signaling-Yourself" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Generating-Signals-1"></a>
<h2 class="section">24.6 Generating Signals</h2>
<a name="index-sending-signals"></a>
<a name="index-raising-signals"></a>
<a name="index-signals_002c-generating"></a>
<p>Besides signals that are generated as a result of a hardware trap or
interrupt, your program can explicitly send signals to itself or to
another process.
</p>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#Signaling-Yourself">24.6.1 Signaling Yourself</a></td><td> </td><td align="left" valign="top"> A process can send a signal to itself.
</td></tr>
<tr><td align="left" valign="top"><a href="#Signaling-Another-Process">24.6.2 Signaling Another Process</a></td><td> </td><td align="left" valign="top"> Send a signal to another process.
</td></tr>
<tr><td align="left" valign="top"><a href="#Permission-for-kill">24.6.3 Permission for using <code>kill</code></a></td><td> </td><td align="left" valign="top"></td></tr>
<tr><td align="left" valign="top"><a href="#Kill-Example">24.6.4 Using <code>kill</code> for Communication</a></td><td> </td><td align="left" valign="top"></td></tr>
</table>
<hr size="6">
<a name="Signaling-Yourself"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Generating-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Signaling-Another-Process" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Generating-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Signaling-Yourself-1"></a>
<h3 class="subsection">24.6.1 Signaling Yourself</h3>
<p>A process can send itself a signal with the <code>raise</code> function. This
function is declared in ‘<tt>signal.h</tt>’.
<a name="index-signal_002eh-5"></a>
</p>
<dl>
<dt><a name="index-raise"></a><u>Function:</u> int <b>raise</b><i> (int <var>signum</var>)</i></dt>
<dd><p>The <code>raise</code> function sends the signal <var>signum</var> to the calling
process. It returns zero if successful and a nonzero value if it fails.
About the only reason for failure would be if the value of <var>signum</var>
is invalid.
</p></dd></dl>
<dl>
<dt><a name="index-gsignal"></a><u>Function:</u> int <b>gsignal</b><i> (int <var>signum</var>)</i></dt>
<dd><p>The <code>gsignal</code> function does the same thing as <code>raise</code>; it is
provided only for compatibility with SVID.
</p></dd></dl>
<p>One convenient use for <code>raise</code> is to reproduce the default behavior
of a signal that you have trapped. For instance, suppose a user of your
program types the SUSP character (usually <kbd>C-z</kbd>; see section <a href="libc_17.html#Special-Characters">Special Characters</a>) to send it an interactive stop signal
(<code>SIGTSTP</code>), and you want to clean up some internal data buffers
before stopping. You might set this up like this:
</p>
<table><tr><td> </td><td><pre class="smallexample">#include <signal.h>
/* <span class="roman">When a stop signal arrives, set the action back to the default
and then resend the signal after doing cleanup actions.</span> */
void
tstp_handler (int sig)
{
signal (SIGTSTP, SIG_DFL);
/* <span class="roman">Do cleanup actions here.</span> */
…
raise (SIGTSTP);
}
/* <span class="roman">When the process is continued again, restore the signal handler.</span> */
void
cont_handler (int sig)
{
signal (SIGCONT, cont_handler);
signal (SIGTSTP, tstp_handler);
}
</pre><pre class="smallexample">/* <span class="roman">Enable both handlers during program initialization.</span> */
int
main (void)
{
signal (SIGCONT, cont_handler);
signal (SIGTSTP, tstp_handler);
…
}
</pre></td></tr></table>
<p><strong>Portability note:</strong> <code>raise</code> was invented by the ISO C
committee. Older systems may not support it, so using <code>kill</code> may
be more portable. See section <a href="#Signaling-Another-Process">Signaling Another Process</a>.
</p>
<hr size="6">
<a name="Signaling-Another-Process"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Signaling-Yourself" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Permission-for-kill" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Generating-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Signaling-Another-Process-1"></a>
<h3 class="subsection">24.6.2 Signaling Another Process</h3>
<a name="index-killing-a-process"></a>
<p>The <code>kill</code> function can be used to send a signal to another process.
In spite of its name, it can be used for a lot of things other than
causing a process to terminate. Some examples of situations where you
might want to send signals between processes are:
</p>
<ul>
<li>
A parent process starts a child to perform a task—perhaps having the
child running an infinite loop—and then terminates the child when the
task is no longer needed.
</li><li>
A process executes as part of a group, and needs to terminate or notify
the other processes in the group when an error or other event occurs.
</li><li>
Two processes need to synchronize while working together.
</li></ul>
<p>This section assumes that you know a little bit about how processes
work. For more information on this subject, see <a href="libc_26.html#Processes">Processes</a>.
</p>
<p>The <code>kill</code> function is declared in ‘<tt>signal.h</tt>’.
<a name="index-signal_002eh-6"></a>
</p>
<dl>
<dt><a name="index-kill-1"></a><u>Function:</u> int <b>kill</b><i> (pid_t <var>pid</var>, int <var>signum</var>)</i></dt>
<dd><p>The <code>kill</code> function sends the signal <var>signum</var> to the process
or process group specified by <var>pid</var>. Besides the signals listed in
<a href="#Standard-Signals">Standard Signals</a>, <var>signum</var> can also have a value of zero to
check the validity of the <var>pid</var>.
</p>
<p>The <var>pid</var> specifies the process or process group to receive the
signal:
</p>
<dl compact="compact">
<dt> <code><var>pid</var> > 0</code></dt>
<dd><p>The process whose identifier is <var>pid</var>.
</p>
</dd>
<dt> <code><var>pid</var> == 0</code></dt>
<dd><p>All processes in the same process group as the sender.
</p>
</dd>
<dt> <code><var>pid</var> < -1</code></dt>
<dd><p>The process group whose identifier is -<var>pid</var>.
</p>
</dd>
<dt> <code><var>pid</var> == -1</code></dt>
<dd><p>If the process is privileged, send the signal to all processes except
for some special system processes. Otherwise, send the signal to all
processes with the same effective user ID.
</p></dd>
</dl>
<p>A process can send a signal to itself with a call like <code>kill
(getpid(), <var>signum</var>)</code>. If <code>kill</code> is used by a process to send
a signal to itself, and the signal is not blocked, then <code>kill</code>
delivers at least one signal (which might be some other pending
unblocked signal instead of the signal <var>signum</var>) to that process
before it returns.
</p>
<p>The return value from <code>kill</code> is zero if the signal can be sent
successfully. Otherwise, no signal is sent, and a value of <code>-1</code> is
returned. If <var>pid</var> specifies sending a signal to several processes,
<code>kill</code> succeeds if it can send the signal to at least one of them.
There’s no way you can tell which of the processes got the signal
or whether all of them did.
</p>
<p>The following <code>errno</code> error conditions are defined for this function:
</p>
<dl compact="compact">
<dt> <code>EINVAL</code></dt>
<dd><p>The <var>signum</var> argument is an invalid or unsupported number.
</p>
</dd>
<dt> <code>EPERM</code></dt>
<dd><p>You do not have the privilege to send a signal to the process or any of
the processes in the process group named by <var>pid</var>.
</p>
</dd>
<dt> <code>ESRCH</code></dt>
<dd><p>The <var>pid</var> argument does not refer to an existing process or group.
</p></dd>
</dl>
</dd></dl>
<dl>
<dt><a name="index-killpg"></a><u>Function:</u> int <b>killpg</b><i> (int <var>pgid</var>, int <var>signum</var>)</i></dt>
<dd><p>This is similar to <code>kill</code>, but sends signal <var>signum</var> to the
process group <var>pgid</var>. This function is provided for compatibility
with BSD; using <code>kill</code> to do this is more portable.
</p></dd></dl>
<p>As a simple example of <code>kill</code>, the call <code>kill (getpid (),
<var>sig</var>)</code> has the same effect as <code>raise (<var>sig</var>)</code>.
</p>
<hr size="6">
<a name="Permission-for-kill"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Signaling-Another-Process" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Kill-Example" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Generating-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Permission-for-using-kill"></a>
<h3 class="subsection">24.6.3 Permission for using <code>kill</code></h3>
<p>There are restrictions that prevent you from using <code>kill</code> to send
signals to any random process. These are intended to prevent antisocial
behavior such as arbitrarily killing off processes belonging to another
user. In typical use, <code>kill</code> is used to pass signals between
parent, child, and sibling processes, and in these situations you
normally do have permission to send signals. The only common exception
is when you run a setuid program in a child process; if the program
changes its real UID as well as its effective UID, you may not have
permission to send a signal. The <code>su</code> program does this.
</p>
<p>Whether a process has permission to send a signal to another process
is determined by the user IDs of the two processes. This concept is
discussed in detail in <a href="libc_29.html#Process-Persona">The Persona of a Process</a>.
</p>
<p>Generally, for a process to be able to send a signal to another process,
either the sending process must belong to a privileged user (like
‘<samp>root</samp>’), or the real or effective user ID of the sending process
must match the real or effective user ID of the receiving process. If
the receiving process has changed its effective user ID from the
set-user-ID mode bit on its process image file, then the owner of the
process image file is used in place of its current effective user ID.
In some implementations, a parent process might be able to send signals
to a child process even if the user ID’s don’t match, and other
implementations might enforce other restrictions.
</p>
<p>The <code>SIGCONT</code> signal is a special case. It can be sent if the
sender is part of the same session as the receiver, regardless of
user IDs.
</p>
<hr size="6">
<a name="Kill-Example"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Permission-for-kill" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Blocking-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Generating-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Using-kill-for-Communication"></a>
<h3 class="subsection">24.6.4 Using <code>kill</code> for Communication</h3>
<a name="index-interprocess-communication_002c-with-signals"></a>
<p>Here is a longer example showing how signals can be used for
interprocess communication. This is what the <code>SIGUSR1</code> and
<code>SIGUSR2</code> signals are provided for. Since these signals are fatal
by default, the process that is supposed to receive them must trap them
through <code>signal</code> or <code>sigaction</code>.
</p>
<p>In this example, a parent process forks a child process and then waits
for the child to complete its initialization. The child process tells
the parent when it is ready by sending it a <code>SIGUSR1</code> signal, using
the <code>kill</code> function.
</p>
<table><tr><td> </td><td><pre class="smallexample">#include <signal.h>
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
</pre><pre class="smallexample">
/* <span class="roman">When a <code>SIGUSR1</code> signal arrives, set this variable.</span> */
volatile sig_atomic_t usr_interrupt = 0;
void
synch_signal (int sig)
{
usr_interrupt = 1;
}
/* <span class="roman">The child process executes this function.</span> */
void
child_function (void)
{
/* <span class="roman">Perform initialization.</span> */
printf ("I'm here!!! My pid is %d.\n", (int) getpid ());
/* <span class="roman">Let parent know you're done.</span> */
kill (getppid (), SIGUSR1);
/* <span class="roman">Continue with execution.</span> */
puts ("Bye, now....");
exit (0);
}
int
main (void)
{
struct sigaction usr_action;
sigset_t block_mask;
pid_t child_id;
/* <span class="roman">Establish the signal handler.</span> */
sigfillset (&block_mask);
usr_action.sa_handler = synch_signal;
usr_action.sa_mask = block_mask;
usr_action.sa_flags = 0;
sigaction (SIGUSR1, &usr_action, NULL);
/* <span class="roman">Create the child process.</span> */
child_id = fork ();
if (child_id == 0)
child_function (); /* <span class="roman">Does not return.</span> */
</pre><pre class="smallexample"> /* <span class="roman">Busy wait for the child to send a signal.</span> */
while (!usr_interrupt)
;
</pre><pre class="smallexample">
/* <span class="roman">Now continue execution.</span> */
puts ("That's all, folks!");
return 0;
}
</pre></td></tr></table>
<p>This example uses a busy wait, which is bad, because it wastes CPU
cycles that other programs could otherwise use. It is better to ask the
system to wait until the signal arrives. See the example in
<a href="#Waiting-for-a-Signal">Waiting for a Signal</a>.
</p>
<hr size="6">
<a name="Blocking-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Kill-Example" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Why-Block" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Blocking-Signals-1"></a>
<h2 class="section">24.7 Blocking Signals</h2>
<a name="index-blocking-signals"></a>
<p>Blocking a signal means telling the operating system to hold it and
deliver it later. Generally, a program does not block signals
indefinitely—it might as well ignore them by setting their actions to
<code>SIG_IGN</code>. But it is useful to block signals briefly, to prevent
them from interrupting sensitive operations. For instance:
</p>
<ul>
<li>
You can use the <code>sigprocmask</code> function to block signals while you
modify global variables that are also modified by the handlers for these
signals.
</li><li>
You can set <code>sa_mask</code> in your <code>sigaction</code> call to block
certain signals while a particular signal handler runs. This way, the
signal handler can run without being interrupted itself by signals.
</li></ul>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#Why-Block">24.7.1 Why Blocking Signals is Useful</a></td><td> </td><td align="left" valign="top"> The purpose of blocking signals.
</td></tr>
<tr><td align="left" valign="top"><a href="#Signal-Sets">24.7.2 Signal Sets</a></td><td> </td><td align="left" valign="top"> How to specify which signals to
block.
</td></tr>
<tr><td align="left" valign="top"><a href="#Process-Signal-Mask">24.7.3 Process Signal Mask</a></td><td> </td><td align="left" valign="top"> Blocking delivery of signals to your
process during normal execution.
</td></tr>
<tr><td align="left" valign="top"><a href="#Testing-for-Delivery">24.7.4 Blocking to Test for Delivery of a Signal</a></td><td> </td><td align="left" valign="top"></td></tr>
<tr><td align="left" valign="top"><a href="#Blocking-for-Handler">24.7.5 Blocking Signals for a Handler</a></td><td> </td><td align="left" valign="top"> Blocking additional signals while a
handler is being run.
</td></tr>
<tr><td align="left" valign="top"><a href="#Checking-for-Pending-Signals">24.7.6 Checking for Pending Signals</a></td><td> </td><td align="left" valign="top"></td></tr>
<tr><td align="left" valign="top"><a href="#Remembering-a-Signal">24.7.7 Remembering a Signal to Act On Later</a></td><td> </td><td align="left" valign="top"> How you can get almost the same
effect as blocking a signal, by
handling it and setting a flag
to be tested later.
</td></tr>
</table>
<hr size="6">
<a name="Why-Block"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Blocking-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Sets" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Blocking-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Why-Blocking-Signals-is-Useful"></a>
<h3 class="subsection">24.7.1 Why Blocking Signals is Useful</h3>
<p>Temporary blocking of signals with <code>sigprocmask</code> gives you a way to
prevent interrupts during critical parts of your code. If signals
arrive in that part of the program, they are delivered later, after you
unblock them.
</p>
<p>One example where this is useful is for sharing data between a signal
handler and the rest of the program. If the type of the data is not
<code>sig_atomic_t</code> (see section <a href="#Atomic-Data-Access">Atomic Data Access and Signal Handling</a>), then the signal
handler could run when the rest of the program has only half finished
reading or writing the data. This would lead to confusing consequences.
</p>
<p>To make the program reliable, you can prevent the signal handler from
running while the rest of the program is examining or modifying that
data—by blocking the appropriate signal around the parts of the
program that touch the data.
</p>
<p>Blocking signals is also necessary when you want to perform a certain
action only if a signal has not arrived. Suppose that the handler for
the signal sets a flag of type <code>sig_atomic_t</code>; you would like to
test the flag and perform the action if the flag is not set. This is
unreliable. Suppose the signal is delivered immediately after you test
the flag, but before the consequent action: then the program will
perform the action even though the signal has arrived.
</p>
<p>The only way to test reliably for whether a signal has yet arrived is to
test while the signal is blocked.
</p>
<hr size="6">
<a name="Signal-Sets"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Why-Block" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Process-Signal-Mask" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Blocking-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Signal-Sets-1"></a>
<h3 class="subsection">24.7.2 Signal Sets</h3>
<p>All of the signal blocking functions use a data structure called a
<em>signal set</em> to specify what signals are affected. Thus, every
activity involves two stages: creating the signal set, and then passing
it as an argument to a library function.
<a name="index-signal-set"></a>
</p>
<p>These facilities are declared in the header file ‘<tt>signal.h</tt>’.
<a name="index-signal_002eh-7"></a>
</p>
<dl>
<dt><a name="index-sigset_005ft"></a><u>Data Type:</u> <b>sigset_t</b></dt>
<dd><p>The <code>sigset_t</code> data type is used to represent a signal set.
Internally, it may be implemented as either an integer or structure
type.
</p>
<p>For portability, use only the functions described in this section to
initialize, change, and retrieve information from <code>sigset_t</code>
objects—don’t try to manipulate them directly.
</p></dd></dl>
<p>There are two ways to initialize a signal set. You can initially
specify it to be empty with <code>sigemptyset</code> and then add specified
signals individually. Or you can specify it to be full with
<code>sigfillset</code> and then delete specified signals individually.
</p>
<p>You must always initialize the signal set with one of these two
functions before using it in any other way. Don’t try to set all the
signals explicitly because the <code>sigset_t</code> object might include some
other information (like a version field) that needs to be initialized as
well. (In addition, it’s not wise to put into your program an
assumption that the system has no signals aside from the ones you know
about.)
</p>
<dl>
<dt><a name="index-sigemptyset"></a><u>Function:</u> int <b>sigemptyset</b><i> (sigset_t *<var>set</var>)</i></dt>
<dd><p>This function initializes the signal set <var>set</var> to exclude all of the
defined signals. It always returns <code>0</code>.
</p></dd></dl>
<dl>
<dt><a name="index-sigfillset"></a><u>Function:</u> int <b>sigfillset</b><i> (sigset_t *<var>set</var>)</i></dt>
<dd><p>This function initializes the signal set <var>set</var> to include
all of the defined signals. Again, the return value is <code>0</code>.
</p></dd></dl>
<dl>
<dt><a name="index-sigaddset"></a><u>Function:</u> int <b>sigaddset</b><i> (sigset_t *<var>set</var>, int <var>signum</var>)</i></dt>
<dd><p>This function adds the signal <var>signum</var> to the signal set <var>set</var>.
All <code>sigaddset</code> does is modify <var>set</var>; it does not block or
unblock any signals.
</p>
<p>The return value is <code>0</code> on success and <code>-1</code> on failure.
The following <code>errno</code> error condition is defined for this function:
</p>
<dl compact="compact">
<dt> <code>EINVAL</code></dt>
<dd><p>The <var>signum</var> argument doesn’t specify a valid signal.
</p></dd>
</dl>
</dd></dl>
<dl>
<dt><a name="index-sigdelset"></a><u>Function:</u> int <b>sigdelset</b><i> (sigset_t *<var>set</var>, int <var>signum</var>)</i></dt>
<dd><p>This function removes the signal <var>signum</var> from the signal set
<var>set</var>. All <code>sigdelset</code> does is modify <var>set</var>; it does not
block or unblock any signals. The return value and error conditions are
the same as for <code>sigaddset</code>.
</p></dd></dl>
<p>Finally, there is a function to test what signals are in a signal set:
</p>
<dl>
<dt><a name="index-sigismember"></a><u>Function:</u> int <b>sigismember</b><i> (const sigset_t *<var>set</var>, int <var>signum</var>)</i></dt>
<dd><p>The <code>sigismember</code> function tests whether the signal <var>signum</var> is
a member of the signal set <var>set</var>. It returns <code>1</code> if the signal
is in the set, <code>0</code> if not, and <code>-1</code> if there is an error.
</p>
<p>The following <code>errno</code> error condition is defined for this function:
</p>
<dl compact="compact">
<dt> <code>EINVAL</code></dt>
<dd><p>The <var>signum</var> argument doesn’t specify a valid signal.
</p></dd>
</dl>
</dd></dl>
<hr size="6">
<a name="Process-Signal-Mask"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Signal-Sets" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Testing-for-Delivery" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Blocking-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Process-Signal-Mask-1"></a>
<h3 class="subsection">24.7.3 Process Signal Mask</h3>
<a name="index-signal-mask"></a>
<a name="index-process-signal-mask"></a>
<p>The collection of signals that are currently blocked is called the
<em>signal mask</em>. Each process has its own signal mask. When you
create a new process (see section <a href="libc_26.html#Creating-a-Process">Creating a Process</a>), it inherits its
parent’s mask. You can block or unblock signals with total flexibility
by modifying the signal mask.
</p>
<p>The prototype for the <code>sigprocmask</code> function is in ‘<tt>signal.h</tt>’.
<a name="index-signal_002eh-8"></a>
</p>
<p>Note that you must not use <code>sigprocmask</code> in multi-threaded processes,
because each thread has its own signal mask and there is no single process
signal mask. According to POSIX, the behavior of <code>sigprocmask</code> in a
multi-threaded process is “unspecified”.
Instead, use <code>pthread_sigmask</code>.
</p>
<dl>
<dt><a name="index-sigprocmask"></a><u>Function:</u> int <b>sigprocmask</b><i> (int <var>how</var>, const sigset_t *restrict <var>set</var>, sigset_t *restrict <var>oldset</var>)</i></dt>
<dd><p>The <code>sigprocmask</code> function is used to examine or change the calling
process’s signal mask. The <var>how</var> argument determines how the signal
mask is changed, and must be one of the following values:
</p>
<dl compact="compact">
<dd><a name="index-SIG_005fBLOCK"></a>
</dd>
<dt> <code>SIG_BLOCK</code></dt>
<dd><p>Block the signals in <code>set</code>—add them to the existing mask. In
other words, the new mask is the union of the existing mask and
<var>set</var>.
</p>
<a name="index-SIG_005fUNBLOCK"></a>
</dd>
<dt> <code>SIG_UNBLOCK</code></dt>
<dd><p>Unblock the signals in <var>set</var>—remove them from the existing mask.
</p>
<a name="index-SIG_005fSETMASK"></a>
</dd>
<dt> <code>SIG_SETMASK</code></dt>
<dd><p>Use <var>set</var> for the mask; ignore the previous value of the mask.
</p></dd>
</dl>
<p>The last argument, <var>oldset</var>, is used to return information about the
old process signal mask. If you just want to change the mask without
looking at it, pass a null pointer as the <var>oldset</var> argument.
Similarly, if you want to know what’s in the mask without changing it,
pass a null pointer for <var>set</var> (in this case the <var>how</var> argument
is not significant). The <var>oldset</var> argument is often used to
remember the previous signal mask in order to restore it later. (Since
the signal mask is inherited over <code>fork</code> and <code>exec</code> calls, you
can’t predict what its contents are when your program starts running.)
</p>
<p>If invoking <code>sigprocmask</code> causes any pending signals to be
unblocked, at least one of those signals is delivered to the process
before <code>sigprocmask</code> returns. The order in which pending signals
are delivered is not specified, but you can control the order explicitly
by making multiple <code>sigprocmask</code> calls to unblock various signals
one at a time.
</p>
<p>The <code>sigprocmask</code> function returns <code>0</code> if successful, and <code>-1</code>
to indicate an error. The following <code>errno</code> error conditions are
defined for this function:
</p>
<dl compact="compact">
<dt> <code>EINVAL</code></dt>
<dd><p>The <var>how</var> argument is invalid.
</p></dd>
</dl>
<p>You can’t block the <code>SIGKILL</code> and <code>SIGSTOP</code> signals, but
if the signal set includes these, <code>sigprocmask</code> just ignores
them instead of returning an error status.
</p>
<p>Remember, too, that blocking program error signals such as <code>SIGFPE</code>
leads to undesirable results for signals generated by an actual program
error (as opposed to signals sent with <code>raise</code> or <code>kill</code>).
This is because your program may be too broken to be able to continue
executing to a point where the signal is unblocked again.
See section <a href="#Program-Error-Signals">Program Error Signals</a>.
</p></dd></dl>
<hr size="6">
<a name="Testing-for-Delivery"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Process-Signal-Mask" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Blocking-for-Handler" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Blocking-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Blocking-to-Test-for-Delivery-of-a-Signal"></a>
<h3 class="subsection">24.7.4 Blocking to Test for Delivery of a Signal</h3>
<p>Now for a simple example. Suppose you establish a handler for
<code>SIGALRM</code> signals that sets a flag whenever a signal arrives, and
your main program checks this flag from time to time and then resets it.
You can prevent additional <code>SIGALRM</code> signals from arriving in the
meantime by wrapping the critical part of the code with calls to
<code>sigprocmask</code>, like this:
</p>
<table><tr><td> </td><td><pre class="smallexample">/* <span class="roman">This variable is set by the SIGALRM signal handler.</span> */
volatile sig_atomic_t flag = 0;
int
main (void)
{
sigset_t block_alarm;
…
/* <span class="roman">Initialize the signal mask.</span> */
sigemptyset (&block_alarm);
sigaddset (&block_alarm, SIGALRM);
</pre><pre class="smallexample"> while (1)
{
/* <span class="roman">Check if a signal has arrived; if so, reset the flag.</span> */
sigprocmask (SIG_BLOCK, &block_alarm, NULL);
if (flag)
{
<var>actions-if-not-arrived</var>
flag = 0;
}
sigprocmask (SIG_UNBLOCK, &block_alarm, NULL);
…
}
}
</pre></td></tr></table>
<hr size="6">
<a name="Blocking-for-Handler"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Testing-for-Delivery" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Checking-for-Pending-Signals" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Blocking-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Blocking-Signals-for-a-Handler"></a>
<h3 class="subsection">24.7.5 Blocking Signals for a Handler</h3>
<a name="index-blocking-signals_002c-in-a-handler"></a>
<p>When a signal handler is invoked, you usually want it to be able to
finish without being interrupted by another signal. From the moment the
handler starts until the moment it finishes, you must block signals that
might confuse it or corrupt its data.
</p>
<p>When a handler function is invoked on a signal, that signal is
automatically blocked (in addition to any other signals that are already
in the process’s signal mask) during the time the handler is running.
If you set up a handler for <code>SIGTSTP</code>, for instance, then the
arrival of that signal forces further <code>SIGTSTP</code> signals to wait
during the execution of the handler.
</p>
<p>However, by default, other kinds of signals are not blocked; they can
arrive during handler execution.
</p>
<p>The reliable way to block other kinds of signals during the execution of
the handler is to use the <code>sa_mask</code> member of the <code>sigaction</code>
structure.
</p>
<p>Here is an example:
</p>
<table><tr><td> </td><td><pre class="smallexample">#include <signal.h>
#include <stddef.h>
void catch_stop ();
void
install_handler (void)
{
struct sigaction setup_action;
sigset_t block_mask;
sigemptyset (&block_mask);
/* <span class="roman">Block other terminal-generated signals while handler runs.</span> */
sigaddset (&block_mask, SIGINT);
sigaddset (&block_mask, SIGQUIT);
setup_action.sa_handler = catch_stop;
setup_action.sa_mask = block_mask;
setup_action.sa_flags = 0;
sigaction (SIGTSTP, &setup_action, NULL);
}
</pre></td></tr></table>
<p>This is more reliable than blocking the other signals explicitly in the
code for the handler. If you block signals explicitly in the handler,
you can’t avoid at least a short interval at the beginning of the
handler where they are not yet blocked.
</p>
<p>You cannot remove signals from the process’s current mask using this
mechanism. However, you can make calls to <code>sigprocmask</code> within
your handler to block or unblock signals as you wish.
</p>
<p>In any case, when the handler returns, the system restores the mask that
was in place before the handler was entered. If any signals that become
unblocked by this restoration are pending, the process will receive
those signals immediately, before returning to the code that was
interrupted.
</p>
<hr size="6">
<a name="Checking-for-Pending-Signals"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Blocking-for-Handler" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Remembering-a-Signal" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Blocking-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Checking-for-Pending-Signals-1"></a>
<h3 class="subsection">24.7.6 Checking for Pending Signals</h3>
<a name="index-pending-signals_002c-checking-for"></a>
<a name="index-blocked-signals_002c-checking-for"></a>
<a name="index-checking-for-pending-signals"></a>
<p>You can find out which signals are pending at any time by calling
<code>sigpending</code>. This function is declared in ‘<tt>signal.h</tt>’.
<a name="index-signal_002eh-9"></a>
</p>
<dl>
<dt><a name="index-sigpending"></a><u>Function:</u> int <b>sigpending</b><i> (sigset_t *<var>set</var>)</i></dt>
<dd><p>The <code>sigpending</code> function stores information about pending signals
in <var>set</var>. If there is a pending signal that is blocked from
delivery, then that signal is a member of the returned set. (You can
test whether a particular signal is a member of this set using
<code>sigismember</code>; see <a href="#Signal-Sets">Signal Sets</a>.)
</p>
<p>The return value is <code>0</code> if successful, and <code>-1</code> on failure.
</p></dd></dl>
<p>Testing whether a signal is pending is not often useful. Testing when
that signal is not blocked is almost certainly bad design.
</p>
<p>Here is an example.
</p>
<table><tr><td> </td><td><pre class="smallexample">#include <signal.h>
#include <stddef.h>
sigset_t base_mask, waiting_mask;
sigemptyset (&base_mask);
sigaddset (&base_mask, SIGINT);
sigaddset (&base_mask, SIGTSTP);
/* <span class="roman">Block user interrupts while doing other processing.</span> */
sigprocmask (SIG_SETMASK, &base_mask, NULL);
…
/* <span class="roman">After a while, check to see whether any signals are pending.</span> */
sigpending (&waiting_mask);
if (sigismember (&waiting_mask, SIGINT)) {
/* <span class="roman">User has tried to kill the process.</span> */
}
else if (sigismember (&waiting_mask, SIGTSTP)) {
/* <span class="roman">User has tried to stop the process.</span> */
}
</pre></td></tr></table>
<p>Remember that if there is a particular signal pending for your process,
additional signals of that same type that arrive in the meantime might
be discarded. For example, if a <code>SIGINT</code> signal is pending when
another <code>SIGINT</code> signal arrives, your program will probably only
see one of them when you unblock this signal.
</p>
<p><strong>Portability Note:</strong> The <code>sigpending</code> function is new in
POSIX.1. Older systems have no equivalent facility.
</p>
<hr size="6">
<a name="Remembering-a-Signal"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Checking-for-Pending-Signals" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Waiting-for-a-Signal" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Blocking-Signals" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Remembering-a-Signal-to-Act-On-Later"></a>
<h3 class="subsection">24.7.7 Remembering a Signal to Act On Later</h3>
<p>Instead of blocking a signal using the library facilities, you can get
almost the same results by making the handler set a flag to be tested
later, when you “unblock”. Here is an example:
</p>
<table><tr><td> </td><td><pre class="smallexample">/* <span class="roman">If this flag is nonzero, don't handle the signal right away.</span> */
volatile sig_atomic_t signal_pending;
/* <span class="roman">This is nonzero if a signal arrived and was not handled.</span> */
volatile sig_atomic_t defer_signal;
void
handler (int signum)
{
if (defer_signal)
signal_pending = signum;
else
… /* <span class="roman">``Really'' handle the signal.</span> */
}
…
void
update_mumble (int frob)
{
/* <span class="roman">Prevent signals from having immediate effect.</span> */
defer_signal++;
/* <span class="roman">Now update <code>mumble</code>, without worrying about interruption.</span> */
mumble.a = 1;
mumble.b = hack ();
mumble.c = frob;
/* <span class="roman">We have updated <code>mumble</code>. Handle any signal that came in.</span> */
defer_signal--;
if (defer_signal == 0 && signal_pending != 0)
raise (signal_pending);
}
</pre></td></tr></table>
<p>Note how the particular signal that arrives is stored in
<code>signal_pending</code>. That way, we can handle several types of
inconvenient signals with the same mechanism.
</p>
<p>We increment and decrement <code>defer_signal</code> so that nested critical
sections will work properly; thus, if <code>update_mumble</code> were called
with <code>signal_pending</code> already nonzero, signals would be deferred
not only within <code>update_mumble</code>, but also within the caller. This
is also why we do not check <code>signal_pending</code> if <code>defer_signal</code>
is still nonzero.
</p>
<p>The incrementing and decrementing of <code>defer_signal</code> each require more
than one instruction; it is possible for a signal to happen in the
middle. But that does not cause any problem. If the signal happens
early enough to see the value from before the increment or decrement,
that is equivalent to a signal which came before the beginning of the
increment or decrement, which is a case that works properly.
</p>
<p>It is absolutely vital to decrement <code>defer_signal</code> before testing
<code>signal_pending</code>, because this avoids a subtle bug. If we did
these things in the other order, like this,
</p>
<table><tr><td> </td><td><pre class="smallexample"> if (defer_signal == 1 && signal_pending != 0)
raise (signal_pending);
defer_signal--;
</pre></td></tr></table>
<p>then a signal arriving in between the <code>if</code> statement and the decrement
would be effectively “lost” for an indefinite amount of time. The
handler would merely set <code>defer_signal</code>, but the program having
already tested this variable, it would not test the variable again.
</p>
<a name="index-timing-error-in-signal-handling"></a>
<p>Bugs like these are called <em>timing errors</em>. They are especially bad
because they happen only rarely and are nearly impossible to reproduce.
You can’t expect to find them with a debugger as you would find a
reproducible bug. So it is worth being especially careful to avoid
them.
</p>
<p>(You would not be tempted to write the code in this order, given the use
of <code>defer_signal</code> as a counter which must be tested along with
<code>signal_pending</code>. After all, testing for zero is cleaner than
testing for one. But if you did not use <code>defer_signal</code> as a
counter, and gave it values of zero and one only, then either order
might seem equally simple. This is a further advantage of using a
counter for <code>defer_signal</code>: it will reduce the chance you will
write the code in the wrong order and create a subtle bug.)
</p>
<hr size="6">
<a name="Waiting-for-a-Signal"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Remembering-a-Signal" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Using-Pause" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Waiting-for-a-Signal-1"></a>
<h2 class="section">24.8 Waiting for a Signal</h2>
<a name="index-waiting-for-a-signal"></a>
<a name="index-pause-function"></a>
<p>If your program is driven by external events, or uses signals for
synchronization, then when it has nothing to do it should probably wait
until a signal arrives.
</p>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#Using-Pause">24.8.1 Using <code>pause</code></a></td><td> </td><td align="left" valign="top"> The simple way, using <code>pause</code>.
</td></tr>
<tr><td align="left" valign="top"><a href="#Pause-Problems">24.8.2 Problems with <code>pause</code></a></td><td> </td><td align="left" valign="top"> Why the simple way is often not very good.
</td></tr>
<tr><td align="left" valign="top"><a href="#Sigsuspend">24.8.3 Using <code>sigsuspend</code></a></td><td> </td><td align="left" valign="top"> Reliably waiting for a specific signal.
</td></tr>
</table>
<hr size="6">
<a name="Using-Pause"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Waiting-for-a-Signal" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Pause-Problems" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Waiting-for-a-Signal" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Using-pause"></a>
<h3 class="subsection">24.8.1 Using <code>pause</code></h3>
<p>The simple way to wait until a signal arrives is to call <code>pause</code>.
Please read about its disadvantages, in the following section, before
you use it.
</p>
<dl>
<dt><a name="index-pause"></a><u>Function:</u> int <b>pause</b><i> ()</i></dt>
<dd><p>The <code>pause</code> function suspends program execution until a signal
arrives whose action is either to execute a handler function, or to
terminate the process.
</p>
<p>If the signal causes a handler function to be executed, then
<code>pause</code> returns. This is considered an unsuccessful return (since
“successful” behavior would be to suspend the program forever), so the
return value is <code>-1</code>. Even if you specify that other primitives
should resume when a system handler returns (see section <a href="#Interrupted-Primitives">Primitives Interrupted by Signals</a>), this has no effect on <code>pause</code>; it always fails when a
signal is handled.
</p>
<p>The following <code>errno</code> error conditions are defined for this function:
</p>
<dl compact="compact">
<dt> <code>EINTR</code></dt>
<dd><p>The function was interrupted by delivery of a signal.
</p></dd>
</dl>
<p>If the signal causes program termination, <code>pause</code> doesn’t return
(obviously).
</p>
<p>This function is a cancellation point in multithreaded programs. This
is a problem if the thread allocates some resources (like memory, file
descriptors, semaphores or whatever) at the time <code>pause</code> is
called. If the thread gets cancelled these resources stay allocated
until the program ends. To avoid this calls to <code>pause</code> should be
protected using cancellation handlers.
</p>
<p>The <code>pause</code> function is declared in ‘<tt>unistd.h</tt>’.
</p></dd></dl>
<hr size="6">
<a name="Pause-Problems"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Using-Pause" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Sigsuspend" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Waiting-for-a-Signal" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Problems-with-pause"></a>
<h3 class="subsection">24.8.2 Problems with <code>pause</code></h3>
<p>The simplicity of <code>pause</code> can conceal serious timing errors that
can make a program hang mysteriously.
</p>
<p>It is safe to use <code>pause</code> if the real work of your program is done
by the signal handlers themselves, and the “main program” does nothing
but call <code>pause</code>. Each time a signal is delivered, the handler
will do the next batch of work that is to be done, and then return, so
that the main loop of the program can call <code>pause</code> again.
</p>
<p>You can’t safely use <code>pause</code> to wait until one more signal arrives,
and then resume real work. Even if you arrange for the signal handler
to cooperate by setting a flag, you still can’t use <code>pause</code>
reliably. Here is an example of this problem:
</p>
<table><tr><td> </td><td><pre class="smallexample">/* <span class="roman"><code>usr_interrupt</code> is set by the signal handler.</span> */
if (!usr_interrupt)
pause ();
/* <span class="roman">Do work once the signal arrives.</span> */
…
</pre></td></tr></table>
<p>This has a bug: the signal could arrive after the variable
<code>usr_interrupt</code> is checked, but before the call to <code>pause</code>.
If no further signals arrive, the process would never wake up again.
</p>
<p>You can put an upper limit on the excess waiting by using <code>sleep</code>
in a loop, instead of using <code>pause</code>. (See section <a href="libc_21.html#Sleeping">Sleeping</a>, for more
about <code>sleep</code>.) Here is what this looks like:
</p>
<table><tr><td> </td><td><pre class="smallexample">/* <span class="roman"><code>usr_interrupt</code> is set by the signal handler.</span>
while (!usr_interrupt)
sleep (1);
/* <span class="roman">Do work once the signal arrives.</span> */
…
</pre></td></tr></table>
<p>For some purposes, that is good enough. But with a little more
complexity, you can wait reliably until a particular signal handler is
run, using <code>sigsuspend</code>.
</p>
<hr size="6">
<a name="Sigsuspend"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Pause-Problems" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Stack" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Waiting-for-a-Signal" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Using-sigsuspend"></a>
<h3 class="subsection">24.8.3 Using <code>sigsuspend</code></h3>
<p>The clean and reliable way to wait for a signal to arrive is to block it
and then use <code>sigsuspend</code>. By using <code>sigsuspend</code> in a loop,
you can wait for certain kinds of signals, while letting other kinds of
signals be handled by their handlers.
</p>
<dl>
<dt><a name="index-sigsuspend"></a><u>Function:</u> int <b>sigsuspend</b><i> (const sigset_t *<var>set</var>)</i></dt>
<dd><p>This function replaces the process’s signal mask with <var>set</var> and then
suspends the process until a signal is delivered whose action is either
to terminate the process or invoke a signal handling function. In other
words, the program is effectively suspended until one of the signals that
is not a member of <var>set</var> arrives.
</p>
<p>If the process is woken up by delivery of a signal that invokes a handler
function, and the handler function returns, then <code>sigsuspend</code> also
returns.
</p>
<p>The mask remains <var>set</var> only as long as <code>sigsuspend</code> is waiting.
The function <code>sigsuspend</code> always restores the previous signal mask
when it returns.
</p>
<p>The return value and error conditions are the same as for <code>pause</code>.
</p></dd></dl>
<p>With <code>sigsuspend</code>, you can replace the <code>pause</code> or <code>sleep</code>
loop in the previous section with something completely reliable:
</p>
<table><tr><td> </td><td><pre class="smallexample">sigset_t mask, oldmask;
…
/* <span class="roman">Set up the mask of signals to temporarily block.</span> */
sigemptyset (&mask);
sigaddset (&mask, SIGUSR1);
…
/* <span class="roman">Wait for a signal to arrive.</span> */
sigprocmask (SIG_BLOCK, &mask, &oldmask);
while (!usr_interrupt)
sigsuspend (&oldmask);
sigprocmask (SIG_UNBLOCK, &mask, NULL);
</pre></td></tr></table>
<p>This last piece of code is a little tricky. The key point to remember
here is that when <code>sigsuspend</code> returns, it resets the process’s
signal mask to the original value, the value from before the call to
<code>sigsuspend</code>—in this case, the <code>SIGUSR1</code> signal is once
again blocked. The second call to <code>sigprocmask</code> is
necessary to explicitly unblock this signal.
</p>
<p>One other point: you may be wondering why the <code>while</code> loop is
necessary at all, since the program is apparently only waiting for one
<code>SIGUSR1</code> signal. The answer is that the mask passed to
<code>sigsuspend</code> permits the process to be woken up by the delivery of
other kinds of signals, as well—for example, job control signals. If
the process is woken up by a signal that doesn’t set
<code>usr_interrupt</code>, it just suspends itself again until the “right”
kind of signal eventually arrives.
</p>
<p>This technique takes a few more lines of preparation, but that is needed
just once for each kind of wait criterion you want to use. The code
that actually waits is just four lines.
</p>
<hr size="6">
<a name="Signal-Stack"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Sigsuspend" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#BSD-Signal-Handling" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="Using-a-Separate-Signal-Stack"></a>
<h2 class="section">24.9 Using a Separate Signal Stack</h2>
<p>A signal stack is a special area of memory to be used as the execution
stack during signal handlers. It should be fairly large, to avoid any
danger that it will overflow in turn; the macro <code>SIGSTKSZ</code> is
defined to a canonical size for signal stacks. You can use
<code>malloc</code> to allocate the space for the stack. Then call
<code>sigaltstack</code> or <code>sigstack</code> to tell the system to use that
space for the signal stack.
</p>
<p>You don’t need to write signal handlers differently in order to use a
signal stack. Switching from one stack to the other happens
automatically. (Some non-GNU debuggers on some machines may get
confused if you examine a stack trace while a handler that uses the
signal stack is running.)
</p>
<p>There are two interfaces for telling the system to use a separate signal
stack. <code>sigstack</code> is the older interface, which comes from 4.2
BSD. <code>sigaltstack</code> is the newer interface, and comes from 4.4
BSD. The <code>sigaltstack</code> interface has the advantage that it does
not require your program to know which direction the stack grows, which
depends on the specific machine and operating system.
</p>
<dl>
<dt><a name="index-stack_005ft"></a><u>Data Type:</u> <b>stack_t</b></dt>
<dd><p>This structure describes a signal stack. It contains the following members:
</p>
<dl compact="compact">
<dt> <code>void *ss_sp</code></dt>
<dd><p>This points to the base of the signal stack.
</p>
</dd>
<dt> <code>size_t ss_size</code></dt>
<dd><p>This is the size (in bytes) of the signal stack which ‘<samp>ss_sp</samp>’ points to.
You should set this to however much space you allocated for the stack.
</p>
<p>There are two macros defined in ‘<tt>signal.h</tt>’ that you should use in
calculating this size:
</p>
<dl compact="compact">
<dt> <code>SIGSTKSZ</code>
<a name="index-SIGSTKSZ"></a>
</dt>
<dd><p>This is the canonical size for a signal stack. It is judged to be
sufficient for normal uses.
</p>
</dd>
<dt> <code>MINSIGSTKSZ</code>
<a name="index-MINSIGSTKSZ"></a>
</dt>
<dd><p>This is the amount of signal stack space the operating system needs just
to implement signal delivery. The size of a signal stack <strong>must</strong>
be greater than this.
</p>
<p>For most cases, just using <code>SIGSTKSZ</code> for <code>ss_size</code> is
sufficient. But if you know how much stack space your program’s signal
handlers will need, you may want to use a different size. In this case,
you should allocate <code>MINSIGSTKSZ</code> additional bytes for the signal
stack and increase <code>ss_size</code> accordingly.
</p></dd>
</dl>
</dd>
<dt> <code>int ss_flags</code></dt>
<dd><p>This field contains the bitwise <small>OR</small> of these flags:
</p>
<dl compact="compact">
<dt> <code>SS_DISABLE</code>
<a name="index-SS_005fDISABLE"></a>
</dt>
<dd><p>This tells the system that it should not use the signal stack.
</p>
</dd>
<dt> <code>SS_ONSTACK</code>
<a name="index-SS_005fONSTACK"></a>
</dt>
<dd><p>This is set by the system, and indicates that the signal stack is
currently in use. If this bit is not set, then signals will be
delivered on the normal user stack.
</p></dd>
</dl>
</dd>
</dl>
</dd></dl>
<dl>
<dt><a name="index-sigaltstack"></a><u>Function:</u> int <b>sigaltstack</b><i> (const stack_t *restrict <var>stack</var>, stack_t *restrict <var>oldstack</var>)</i></dt>
<dd><p>The <code>sigaltstack</code> function specifies an alternate stack for use
during signal handling. When a signal is received by the process and
its action indicates that the signal stack is used, the system arranges
a switch to the currently installed signal stack while the handler for
that signal is executed.
</p>
<p>If <var>oldstack</var> is not a null pointer, information about the currently
installed signal stack is returned in the location it points to. If
<var>stack</var> is not a null pointer, then this is installed as the new
stack for use by signal handlers.
</p>
<p>The return value is <code>0</code> on success and <code>-1</code> on failure. If
<code>sigaltstack</code> fails, it sets <code>errno</code> to one of these values:
</p>
<dl compact="compact">
<dt> <code>EINVAL</code></dt>
<dd><p>You tried to disable a stack that was in fact currently in use.
</p>
</dd>
<dt> <code>ENOMEM</code></dt>
<dd><p>The size of the alternate stack was too small.
It must be greater than <code>MINSIGSTKSZ</code>.
</p></dd>
</dl>
</dd></dl>
<p>Here is the older <code>sigstack</code> interface. You should use
<code>sigaltstack</code> instead on systems that have it.
</p>
<dl>
<dt><a name="index-struct-sigstack"></a><u>Data Type:</u> <b>struct sigstack</b></dt>
<dd><p>This structure describes a signal stack. It contains the following members:
</p>
<dl compact="compact">
<dt> <code>void *ss_sp</code></dt>
<dd><p>This is the stack pointer. If the stack grows downwards on your
machine, this should point to the top of the area you allocated. If the
stack grows upwards, it should point to the bottom.
</p>
</dd>
<dt> <code>int ss_onstack</code></dt>
<dd><p>This field is true if the process is currently using this stack.
</p></dd>
</dl>
</dd></dl>
<dl>
<dt><a name="index-sigstack"></a><u>Function:</u> int <b>sigstack</b><i> (const struct sigstack *<var>stack</var>, struct sigstack *<var>oldstack</var>)</i></dt>
<dd><p>The <code>sigstack</code> function specifies an alternate stack for use during
signal handling. When a signal is received by the process and its
action indicates that the signal stack is used, the system arranges a
switch to the currently installed signal stack while the handler for
that signal is executed.
</p>
<p>If <var>oldstack</var> is not a null pointer, information about the currently
installed signal stack is returned in the location it points to. If
<var>stack</var> is not a null pointer, then this is installed as the new
stack for use by signal handlers.
</p>
<p>The return value is <code>0</code> on success and <code>-1</code> on failure.
</p></dd></dl>
<hr size="6">
<a name="BSD-Signal-Handling"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Signal-Stack" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#BSD-Handler" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="BSD-Signal-Handling-1"></a>
<h2 class="section">24.10 BSD Signal Handling</h2>
<p>This section describes alternative signal handling functions derived
from BSD Unix. These facilities were an advance, in their time; today,
they are mostly obsolete, and supported mainly for compatibility with
BSD Unix.
</p>
<p>There are many similarities between the BSD and POSIX signal handling
facilities, because the POSIX facilities were inspired by the BSD
facilities. Besides having different names for all the functions to
avoid conflicts, the main differences between the two are:
</p>
<ul>
<li>
BSD Unix represents signal masks as an <code>int</code> bit mask, rather than
as a <code>sigset_t</code> object.
</li><li>
The BSD facilities use a different default for whether an interrupted
primitive should fail or resume. The POSIX facilities make system
calls fail unless you specify that they should resume. With the BSD
facility, the default is to make system calls resume unless you say they
should fail. See section <a href="#Interrupted-Primitives">Primitives Interrupted by Signals</a>.
</li></ul>
<p>The BSD facilities are declared in ‘<tt>signal.h</tt>’.
<a name="index-signal_002eh-10"></a>
</p>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top"><a href="#BSD-Handler">24.10.1 BSD Function to Establish a Handler</a></td><td> </td><td align="left" valign="top"></td></tr>
<tr><td align="left" valign="top"><a href="#Blocking-in-BSD">24.10.2 BSD Functions for Blocking Signals</a></td><td> </td><td align="left" valign="top"></td></tr>
</table>
<hr size="6">
<a name="BSD-Handler"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#BSD-Signal-Handling" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="#Blocking-in-BSD" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#BSD-Signal-Handling" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="BSD-Function-to-Establish-a-Handler"></a>
<h3 class="subsection">24.10.1 BSD Function to Establish a Handler</h3>
<dl>
<dt><a name="index-struct-sigvec"></a><u>Data Type:</u> <b>struct sigvec</b></dt>
<dd><p>This data type is the BSD equivalent of <code>struct sigaction</code>
(see section <a href="#Advanced-Signal-Handling">Advanced Signal Handling</a>); it is used to specify signal actions
to the <code>sigvec</code> function. It contains the following members:
</p>
<dl compact="compact">
<dt> <code>sighandler_t sv_handler</code></dt>
<dd><p>This is the handler function.
</p>
</dd>
<dt> <code>int sv_mask</code></dt>
<dd><p>This is the mask of additional signals to be blocked while the handler
function is being called.
</p>
</dd>
<dt> <code>int sv_flags</code></dt>
<dd><p>This is a bit mask used to specify various flags which affect the
behavior of the signal. You can also refer to this field as
<code>sv_onstack</code>.
</p></dd>
</dl>
</dd></dl>
<p>These symbolic constants can be used to provide values for the
<code>sv_flags</code> field of a <code>sigvec</code> structure. This field is a bit
mask value, so you bitwise-OR the flags of interest to you together.
</p>
<dl>
<dt><a name="index-SV_005fONSTACK"></a><u>Macro:</u> int <b>SV_ONSTACK</b></dt>
<dd><p>If this bit is set in the <code>sv_flags</code> field of a <code>sigvec</code>
structure, it means to use the signal stack when delivering the signal.
</p></dd></dl>
<dl>
<dt><a name="index-SV_005fINTERRUPT"></a><u>Macro:</u> int <b>SV_INTERRUPT</b></dt>
<dd><p>If this bit is set in the <code>sv_flags</code> field of a <code>sigvec</code>
structure, it means that system calls interrupted by this kind of signal
should not be restarted if the handler returns; instead, the system
calls should return with a <code>EINTR</code> error status. See section <a href="#Interrupted-Primitives">Primitives Interrupted by Signals</a>.
</p></dd></dl>
<dl>
<dt><a name="index-SV_005fRESETHAND"></a><u>Macro:</u> int <b>SV_RESETHAND</b></dt>
<dd><p>If this bit is set in the <code>sv_flags</code> field of a <code>sigvec</code>
structure, it means to reset the action for the signal back to
<code>SIG_DFL</code> when the signal is received.
</p></dd></dl>
<dl>
<dt><a name="index-sigvec"></a><u>Function:</u> int <b>sigvec</b><i> (int <var>signum</var>, const struct sigvec *<var>action</var>,struct sigvec *<var>old-action</var>)</i></dt>
<dd><p>This function is the equivalent of <code>sigaction</code> (see section <a href="#Advanced-Signal-Handling">Advanced Signal Handling</a>); it installs the action <var>action</var> for the signal <var>signum</var>,
returning information about the previous action in effect for that signal
in <var>old-action</var>.
</p></dd></dl>
<dl>
<dt><a name="index-siginterrupt"></a><u>Function:</u> int <b>siginterrupt</b><i> (int <var>signum</var>, int <var>failflag</var>)</i></dt>
<dd><p>This function specifies which approach to use when certain primitives
are interrupted by handling signal <var>signum</var>. If <var>failflag</var> is
false, signal <var>signum</var> restarts primitives. If <var>failflag</var> is
true, handling <var>signum</var> causes these primitives to fail with error
code <code>EINTR</code>. See section <a href="#Interrupted-Primitives">Primitives Interrupted by Signals</a>.
</p></dd></dl>
<hr size="6">
<a name="Blocking-in-BSD"></a>
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#BSD-Handler" title="Previous section in reading order"> < </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next section in reading order"> > </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="#BSD-Signal-Handling" title="Up section"> Up </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<a name="BSD-Functions-for-Blocking-Signals"></a>
<h3 class="subsection">24.10.2 BSD Functions for Blocking Signals</h3>
<dl>
<dt><a name="index-sigmask"></a><u>Macro:</u> int <b>sigmask</b><i> (int <var>signum</var>)</i></dt>
<dd><p>This macro returns a signal mask that has the bit for signal <var>signum</var>
set. You can bitwise-OR the results of several calls to <code>sigmask</code>
together to specify more than one signal. For example,
</p>
<table><tr><td> </td><td><pre class="smallexample">(sigmask (SIGTSTP) | sigmask (SIGSTOP)
| sigmask (SIGTTIN) | sigmask (SIGTTOU))
</pre></td></tr></table>
<p>specifies a mask that includes all the job-control stop signals.
</p></dd></dl>
<dl>
<dt><a name="index-sigblock"></a><u>Function:</u> int <b>sigblock</b><i> (int <var>mask</var>)</i></dt>
<dd><p>This function is equivalent to <code>sigprocmask</code> (see section <a href="#Process-Signal-Mask">Process Signal Mask</a>) with a <var>how</var> argument of <code>SIG_BLOCK</code>: it adds the
signals specified by <var>mask</var> to the calling process’s set of blocked
signals. The return value is the previous set of blocked signals.
</p></dd></dl>
<dl>
<dt><a name="index-sigsetmask"></a><u>Function:</u> int <b>sigsetmask</b><i> (int <var>mask</var>)</i></dt>
<dd><p>This function equivalent to <code>sigprocmask</code> (see section <a href="#Process-Signal-Mask">Process Signal Mask</a>) with a <var>how</var> argument of <code>SIG_SETMASK</code>: it sets
the calling process’s signal mask to <var>mask</var>. The return value is
the previous set of blocked signals.
</p></dd></dl>
<dl>
<dt><a name="index-sigpause"></a><u>Function:</u> int <b>sigpause</b><i> (int <var>mask</var>)</i></dt>
<dd><p>This function is the equivalent of <code>sigsuspend</code> (see section <a href="#Waiting-for-a-Signal">Waiting for a Signal</a>): it sets the calling process’s signal mask to <var>mask</var>,
and waits for a signal to arrive. On return the previous set of blocked
signals is restored.
</p></dd></dl>
<hr size="6">
<table cellpadding="1" cellspacing="1" border="0">
<tr><td valign="middle" align="left">[<a href="#Signal-Handling" title="Beginning of this chapter or previous chapter"> << </a>]</td>
<td valign="middle" align="left">[<a href="libc_25.html#Program-Basics" title="Next chapter"> >> </a>]</td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left"> </td>
<td valign="middle" align="left">[<a href="libc.html#Top" title="Cover (top) of document">Top</a>]</td>
<td valign="middle" align="left">[<a href="libc_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td>
<td valign="middle" align="left">[<a href="libc_42.html#Concept-Index" title="Index">Index</a>]</td>
<td valign="middle" align="left">[<a href="libc_abt.html#SEC_About" title="About (help)"> ? </a>]</td>
</tr></table>
<p>
<font size="-1">
This document was generated by <em>root</em> on <em>April 20, 2012</em> using <a href="http://www.nongnu.org/texi2html/"><em>texi2html 1.82</em></a>.
</font>
<br>
</p>
</body>
</html>
|