Lines Matching refs:it
13 particular kind of event. Some kinds of events make it inadvisable or
19 function and tell the operating system to run it when that particular
73 terminate it with @kbd{C-c}. Whatever key sequence is used, the
111 but it does not raise a signal; instead, @code{open} returns @code{-1}.
151 When a signal is generated, it becomes @dfn{pending}. Normally it
154 of signal is currently @dfn{blocked}, it may remain pending
156 unblocked, it will be delivered immediately. @xref{Blocking Signals}.
172 If the specified action for a kind of signal is to ignore it, then any
177 it.
189 more detail in @ref{Process Completion}.) The information it can get
195 property: when one of these signals terminates the process, it also
201 terminates the process, it makes a core dump file just as if the signal
255 signal that happened and then reraising it; this will cause the program
256 to terminate with that signal, as if it had not had a handler.
272 When one of these program error signals terminates a process, it also
307 which means you must cast it to a one-argument function type in order to
336 C never uses it.)
352 The name of this signal is derived from ``illegal instruction''; it
372 the memory that is allocated for it, or to write memory that can only be
417 probably only see @code{SIGTRAP} if it is somehow executing bad
447 the default action for the signal that happened and then reraising it;
448 this will cause the program to terminate with that signal, as if it had
479 The @code{SIGQUIT} signal is similar to @code{SIGINT}, except that it's
481 @kbd{C-\}---and produces a core dump when it terminates the process,
490 For example, if the program creates temporary files, it should handle
491 the other termination requests by deleting the temporary files. But it
502 This signal is usually generated only by explicit request. Since it
503 cannot be handled, you should generate it only as a last resort, after
506 it a @code{SIGKILL} signal will almost always cause it to go away.
623 The default action for this signal is to ignore it. If you establish a
639 You can send a @code{SIGCONT} signal to a process to make it continue.
640 This signal is special---it always makes the process continue if it is
648 it is stopped and continued---for example, to reprint a prompt when it
677 A process cannot read from the user's terminal while it is running
696 While a process is stopped, no more signals can be delivered to it until
697 it is continued, except @code{SIGKILL} signals and (obviously)
701 or ignored. You can ignore @code{SIGCONT}, but it always causes the
702 process to be continued anyway if it is stopped. Sending a
705 signals for a process are discarded when it receives a stop signal.
709 signal and does not handle it, the process does not stop. Stopping the
711 program that will notice it stop and allow the user to continue it.
719 On @gnuhurdsystems{}, it is possible to reattach to the orphaned process
720 group and continue it, so stop signals do stop the process as usual on
721 @gnuhurdsystems{} unless you have requested POSIX compatibility ``till it
772 attempts to extend a file so it exceeds the process's soft resource
780 will not affect your program unless it explicitly uses them for something.
801 the screen is changed. The default action is to ignore it.
803 If a program does full-screen display, it should handle @code{SIGWINCH}.
804 When the signal arrives, it should fetch the new screen size and
829 termination status of a child process (@pxref{Process Completion}) or it
850 should not modify the contents of this string; and, since it can be
851 rewritten on subsequent calls, you should save a copy of it if you need
852 to reference it later.
1005 If you set the action for a signal to @code{SIG_IGN}, or if you set it
1014 restore it later by calling @code{signal} again.
1016 If @code{signal} can't honor the request, it returns @code{SIG_ERR}
1028 @code{signal} function is that it has different semantics on BSD and
1036 is better to use @code{sigaction} if it is available since the results
1071 often ignore certain signals when starting children, and it is important
1097 The @code{ssignal} function does the same thing as @code{signal}; it is
1150 handler, you must write code in the handler to unblock it.
1166 old action in effect for the signal was, and restore it later if you
1176 The return value from @code{sigaction} is zero if it succeeds, and
1197 you use @code{signal} to save and later reestablish an action, it may
1203 Since @code{sigaction} is more general, it can properly save and
1204 reestablish any action, regardless of whether it was established
1208 examine it with @code{sigaction}, the handler address that you get may
1211 you can rely on using it as an argument to @code{sigaction}. This
1266 parameters and passes it in the @code{sigaction} call. The usage of
1340 the library function can resume, or it can return failure with error
1354 When a new process is created (@pxref{Creating a Process}), it inherits
1358 their @code{SIG_DFL} handling. (If you think about it a little, this
1399 it when a signal arrives. This is known as @dfn{establishing} the
1411 control to a point where it can recover from the situation that caused
1457 the loop until it has noticed that a @code{SIGALRM} signal has arrived.
1458 This technique is useful because it allows the iteration in progress
1484 @r{it might still get invoked recursively by delivery of some other kind}
1527 Blocking the signal delays its delivery until it is unblocked, once the
1610 value it had before the handler ran. So using @code{sigprocmask} inside
1619 @code{SIG_DFL}, and the handler must re-establish itself each time it
1622 it may arrive before the handler can re-establish itself. Then the
1668 since some time in the past---whenever the program last cleared it to
1711 @r{has data to look at. We do this only after storing it.} */
1749 while scanning the list, but it is much more elegant to guarantee
1753 until it sees that status has been validly stored. This is to make sure
1754 that the status cannot change in the middle of accessing it. Once
1755 @code{p->have_status} is set, it means that the child process is stopped
1756 or terminated, and in either case, it cannot stop or terminate again
1764 remembers the previous value and sees whether it has changed since the
1816 If you call a function in the handler, make sure it is @dfn{reentrant}
1821 A function can be non-reentrant if it uses memory that is not on the
1827 dynamically-allocated object that it finds for itself, then it is
1834 using the value), it will clobber the value that the program asked for.
1837 function that returns information in the same object, or if it always
1846 If a function uses and modifies an object that you supply, then it is
1874 care, because placing an object on a chain is not atomic, and if it is
1896 @code{errno} and restore it before returning normally. This prevents
1924 necessarily @dfn{atomic}. This means that it can take more than one
1981 safe in this program because it is certainly not being called outside
1985 that's not all it can do! On most machines, it takes several
1991 On some machines it may be possible to store a new value in
2005 one it is, and how many bits it contains, may vary from machine to
2029 that there is no problem if it is interrupted.
2031 An interrupt in the middle of testing the flag is safe because either it's
2033 matter, or it will be seen to be nonzero the next time it's tested.
2040 it can also handle a signal in the middle of clearing the flag. (This
2059 can return it, in order to try the call again. Often programmers forget
2070 If it fails and reports error code @code{EINTR},
2071 @code{TEMP_FAILURE_RETRY} evaluates it again, and over and over until
2079 approach: to restart the interrupted primitive, instead of making it
2093 a particular handler should do, it uses a default choice. The default
2102 lists @code{EINTR} among the error codes it can return.
2153 process. It returns zero if successful and a nonzero value if it fails.
2162 The @code{gsignal} function does the same thing as @code{raise}; it is
2169 Characters}) to send it an interactive stop signal
2219 committee. Older systems may not support it, so using @code{kill} may
2227 In spite of its name, it can be used for a lot of things other than
2254 @c The hurd implementation is not a critical section, so it's not
2255 @c immediately obvious that, in case of cancellation, it won't leak
2257 @c Since none of these make it AC-Unsafe, I'm leaving them out.
2289 before it returns.
2294 @code{kill} succeeds if it can send the signal to at least one of them.
2324 @var{pid} value is not reused by the kernel (for example, if it is the
2383 the parent when it is ready by sending it a @code{SIGUSR1} signal, using
2390 This example uses a busy wait, which is bad, because it wastes CPU
2399 Blocking a signal means telling the operating system to hold it and
2400 deliver it later. Generally, a program does not block signals
2401 indefinitely---it might as well ignore them by setting their actions to
2402 @code{SIG_IGN}. But it is useful to block signals briefly, to prevent
2430 handling it and setting a flag
2470 it as an argument to a library function.
2479 Internally, it may be implemented as either an integer or structure
2488 specify it to be empty with @code{sigemptyset} and then add specified
2489 signals individually. Or you can specify it to be full with
2493 functions before using it in any other way. Don't try to set all the
2496 well. (In addition, it's not wise to put into your program an
2519 All @code{sigaddset} does is modify @var{set}; it does not block or
2535 @var{set}. All @code{sigdelset} does is modify @var{set}; it does not
2564 create a new process (@pxref{Creating a Process}), it inherits its
2608 looking at it, pass a null pointer as the @var{oldset} argument.
2609 Similarly, if you want to know what's in the mask without changing it,
2612 remember the previous signal mask in order to restore it later. (Since
2649 your main program checks this flag from time to time and then resets it.
2691 When a signal handler is invoked, you usually want it to be able to
2693 handler starts until the moment it finishes, you must block signals that
2694 might confuse it or corrupt its data.
2764 @c hurd_self_sigstate, it copies the sigstate's pending while holding
2866 than one instruction; it is possible for a signal to happen in the
2886 already tested this variable, it would not test the variable again.
2892 reproducible bug. So it is worth being especially careful to avoid
2899 counter, and gave it values of zero and one only, then either order
2901 counter for @code{defer_signal}: it will reduce the chance you will
2910 synchronization, then when it has nothing to do it should probably wait
2924 you use it.
2948 Primitives}), this has no effect on @code{pause}; it always fails when a
3026 The clean and reliable way to wait for a signal to arrive is to block it
3057 when it returns.
3084 here is that when @code{sigsuspend} returns, it resets the process's
3096 @code{usr_interrupt}, it just suspends itself again until the ``right''
3108 danger that it will overflow in turn; the macro @code{SIGSTKSZ} is
3123 BSD. The @code{sigaltstack} interface has the advantage that it does
3164 This tells the system that it should not use the signal stack.
3186 installed signal stack is returned in the location it points to. If
3191 @code{sigaltstack} fails, it sets @code{errno} to one of these values:
3204 @code{sigaltstack} instead on systems that have it.
3214 stack grows upwards, it should point to the bottom.
3232 installed signal stack is returned in the location it points to. If
3264 @c bsd_signal reads from, and it may leave _sigintr modified without
3301 @c The exception are BSD systems other than 4.4, where it is a syscall.
3305 Mask}) with a @var{how} argument of @code{SIG_BLOCK}: it adds the
3314 @c The exception are BSD systems other than 4.4, where it is a syscall.
3318 Signal Mask}) with a @var{how} argument of @code{SIG_SETMASK}: it sets
3335 for a Signal}): it sets the calling process's signal mask to @var{mask},