about summary refs log tree commit diff
path: root/manual/signal.texi
diff options
context:
space:
mode:
Diffstat (limited to 'manual/signal.texi')
-rw-r--r--manual/signal.texi12
1 files changed, 6 insertions, 6 deletions
diff --git a/manual/signal.texi b/manual/signal.texi
index 088c35d02f..1a4f866876 100644
--- a/manual/signal.texi
+++ b/manual/signal.texi
@@ -135,7 +135,7 @@ 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.
 
-A given type of signal is either typically synchrous or typically
+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
@@ -608,7 +608,7 @@ code profiling facilities, hence the name of this signal.
 
 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} to enable a particular file descriptior to generate
+calling @code{fcntl} to enable a particular file descriptor to generate
 these signals (@pxref{Interrupt Input}).  The default action for these
 signals is to ignore them.
 
@@ -2310,7 +2310,7 @@ 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} 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 execption
+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} program does this.
@@ -2692,7 +2692,7 @@ install_handler (void)
 @end smallexample
 
 This is more reliable than blocking the other signals explicitly in the
-code for the handler.  If you block signals explicity in the handler,
+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.
 
@@ -2837,7 +2837,7 @@ these things in the other order, like this,
 
 @noindent
 then a signal arriving in between the @code{if} statement and the decrement
-would be effetively ``lost'' for an indefinite amount of time.  The
+would be effectively ``lost'' for an indefinite amount of time.  The
 handler would merely set @code{defer_signal}, but the program having
 already tested this variable, it would not test the variable again.
 
@@ -3081,7 +3081,7 @@ For most cases, just using @code{SIGSTKSZ} for @code{ss_size} 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} additional bytes for the signal
-stack and increase @code{ss_size} accordinly.
+stack and increase @code{ss_size} accordingly.
 @end vtable
 
 @item int ss_flags