diff options
Diffstat (limited to 'manual/signal.texi')
| -rw-r--r-- | manual/signal.texi | 24 |
1 files changed, 12 insertions, 12 deletions
diff --git a/manual/signal.texi b/manual/signal.texi index 15458c208e..08ee785c8c 100644 --- a/manual/signal.texi +++ b/manual/signal.texi @@ -1659,7 +1659,7 @@ the past. Here is an example of a handler for @code{SIGCHLD} that compensates for the fact that the number of signals received may not equal the number of -child processes generate them. It assumes that the program keeps track +child processes that generate them. It assumes that the program keeps track of all the child processes with a chain of structures as follows: @smallexample @@ -1809,7 +1809,7 @@ sig_atomic_t last_process_status_change; 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 at asynchronously, at +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 @@ -1856,8 +1856,8 @@ blocks signals around each use, then you are safe. 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. The description of a function in this -manual always mentions this behavior. +them cause the same problem. Function descriptions in this manual +always mention this behavior. @item If a function uses and modifies an object that you supply, then it is @@ -1940,7 +1940,7 @@ 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 @dfn{atomic}. This means that it can take more than one instruction to read or write a single object. In such cases, a signal -handler might in the middle of reading or writing the object. +handler might be invoked in the middle of reading or writing the object. There are three ways you can cope with this problem. You can use data types that are always accessed atomically; you can carefully arrange @@ -2031,9 +2031,9 @@ atomically. In practice, you can assume that @code{int} and other integer types no longer than @code{int} are atomic. You can also assume that pointer -types are atomic; that is very convenient. Both of these are true on -all of the machines that the GNU C library supports, and on all POSIX -systems we know of. +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. @c ??? This might fail on a 386 that uses 64-bit pointers. @node Atomic Usage @@ -2846,7 +2846,7 @@ not only within @code{update_mumble}, but also within the caller. This is also why we do not check @code{signal_pending} if @code{defer_signal} is still nonzero. -The incrementing and decrementing of @code{defer_signal} require more +The incrementing and decrementing of @code{defer_signal} 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, @@ -2932,12 +2932,12 @@ The function was interrupted by delivery of a signal. If the signal causes program termination, @code{pause} doesn't return (obviously). -This function is a cancelation point in multi-threaded programs. This +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} is -called. If the thread gets canceled these resources stay allocated +called. If the thread gets cancelled these resources stay allocated until the program ends. To avoid this calls to @code{pause} should be -protected using cancelation handlers. +protected using cancellation handlers. @c ref pthread_cleanup_push / pthread_cleanup_pop The @code{pause} function is declared in @file{unistd.h}. |