All of lore.kernel.org
 help / color / mirror / Atom feed
* [patch] pthread_cancel.3, pthread_cleanup_push_defer_np.3, pthread_setcancelstate.3, pthread_testcancel.3, pthreads.7: tfix
@ 2021-11-13 11:56 Samanta Navarro
  2021-11-13 12:40 ` G. Branden Robinson
  0 siblings, 1 reply; 6+ messages in thread
From: Samanta Navarro @ 2021-11-13 11:56 UTC (permalink / raw)
  To: linux-man; +Cc: alx.manpages, mtk.manpages

Changed cancelability to cancellability.

Typo found with codespell.

Signed-off-by: Samanta Navarro <ferivoz@riseup.net>
---
 man3/pthread_cancel.3                | 10 +++++-----
 man3/pthread_cleanup_push_defer_np.3 | 10 +++++-----
 man3/pthread_setcancelstate.3        | 30 ++++++++++++++--------------
 man3/pthread_testcancel.3            |  2 +-
 man7/pthreads.7                      |  4 ++--
 5 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/man3/pthread_cancel.3 b/man3/pthread_cancel.3
index 01b7cf0..9ea1d4a 100644
--- a/man3/pthread_cancel.3
+++ b/man3/pthread_cancel.3
@@ -42,12 +42,12 @@ function sends a cancellation request to the thread
 Whether and when the target thread
 reacts to the cancellation request depends on
 two attributes that are under the control of that thread:
-its cancelability
+its cancellability
 .I state
 and
 .IR type .
 .PP
-A thread's cancelability state, determined by
+A thread's cancellability state, determined by
 .BR pthread_setcancelstate (3),
 can be
 .I enabled
@@ -57,7 +57,7 @@ If a thread has disabled cancellation,
 then a cancellation request remains queued until the thread
 enables cancellation.
 If a thread has enabled cancellation,
-then its cancelability type determines when cancellation occurs.
+then its cancellability type determines when cancellation occurs.
 .PP
 A thread's cancellation type, determined by
 .BR pthread_setcanceltype (3),
@@ -66,10 +66,10 @@ may be either
 or
 .IR deferred
 (the default for new threads).
-Asynchronous cancelability
+Asynchronous cancellability
 means that the thread can be canceled at any time
 (usually immediately, but the system does not guarantee this).
-Deferred cancelability means that cancellation will be delayed until
+Deferred cancellability means that cancellation will be delayed until
 the thread next calls a function that is a
 .IR "cancellation point" .
 A list of functions that are or may be cancellation points is provided in
diff --git a/man3/pthread_cleanup_push_defer_np.3 b/man3/pthread_cleanup_push_defer_np.3
index c5096d1..1daf210 100644
--- a/man3/pthread_cleanup_push_defer_np.3
+++ b/man3/pthread_cleanup_push_defer_np.3
@@ -26,7 +26,7 @@
 .TH PTHREAD_CLEANUP_PUSH_DEFER_NP 3 2021-03-22 "Linux" "Linux Programmer's Manual"
 .SH NAME
 pthread_cleanup_push_defer_np, pthread_cleanup_pop_restore_np \- push and pop
-thread cancellation clean-up handlers while saving cancelability type
+thread cancellation clean-up handlers while saving cancellability type
 .SH SYNOPSIS
 .nf
 .B #include <pthread.h>
@@ -60,11 +60,11 @@ Like
 pushes
 .I routine
 onto the thread's stack of cancellation clean-up handlers.
-In addition, it also saves the thread's current cancelability type,
-and sets the cancelability type to "deferred" (see
+In addition, it also saves the thread's current cancellability type,
+and sets the cancellability type to "deferred" (see
 .BR pthread_setcanceltype (3));
 this ensures that cancellation clean-up will occur
-even if the thread's cancelability type was "asynchronous"
+even if the thread's cancellability type was "asynchronous"
 before the call.
 .PP
 Like
@@ -72,7 +72,7 @@ Like
 .BR pthread_cleanup_pop_restore_np ()
 pops the top-most clean-up handler from the thread's
 stack of cancellation clean-up handlers.
-In addition, it restores the thread's cancelability
+In addition, it restores the thread's cancellability
 type to its value at the time of the matching
 .BR pthread_cleanup_push_defer_np ().
 .PP
diff --git a/man3/pthread_setcancelstate.3 b/man3/pthread_setcancelstate.3
index 56e2acf..5ef6ce6 100644
--- a/man3/pthread_setcancelstate.3
+++ b/man3/pthread_setcancelstate.3
@@ -26,7 +26,7 @@
 .TH PTHREAD_SETCANCELSTATE 3 2021-03-22 "Linux" "Linux Programmer's Manual"
 .SH NAME
 pthread_setcancelstate, pthread_setcanceltype \-
-set cancelability state and type
+set cancellability state and type
 .SH SYNOPSIS
 .nf
 .B #include <pthread.h>
@@ -39,10 +39,10 @@ Compile and link with \fI\-pthread\fP.
 .SH DESCRIPTION
 The
 .BR pthread_setcancelstate ()
-sets the cancelability state of the calling thread to the value
+sets the cancellability state of the calling thread to the value
 given in
 .IR state .
-The previous cancelability state of the thread is returned
+The previous cancellability state of the thread is returned
 in the buffer pointed to by
 .IR oldstate .
 The
@@ -51,22 +51,22 @@ argument must have one of the following values:
 .TP
 .B PTHREAD_CANCEL_ENABLE
 The thread is cancelable.
-This is the default cancelability state in all new threads,
+This is the default cancellability state in all new threads,
 including the initial thread.
-The thread's cancelability type determines when a cancelable thread
+The thread's cancellability type determines when a cancelable thread
 will respond to a cancellation request.
 .TP
 .B PTHREAD_CANCEL_DISABLE
 The thread is not cancelable.
 If a cancellation request is received,
-it is blocked until cancelability is enabled.
+it is blocked until cancellability is enabled.
 .PP
 The
 .BR pthread_setcanceltype ()
-sets the cancelability type of the calling thread to the value
+sets the cancellability type of the calling thread to the value
 given in
 .IR type .
-The previous cancelability type of the thread is returned
+The previous cancellability type of the thread is returned
 in the buffer pointed to by
 .IR oldtype .
 The
@@ -77,7 +77,7 @@ argument must have one of the following values:
 A cancellation request is deferred until the thread next calls
 a function that is a cancellation point (see
 .BR pthreads (7)).
-This is the default cancelability type in all new threads,
+This is the default cancellability type in all new threads,
 including the initial thread.
 .IP
 Even with deferred cancellation, a
@@ -148,14 +148,14 @@ POSIX.1-2001, POSIX.1-2008.
 For details of what happens when a thread is canceled, see
 .BR pthread_cancel (3).
 .PP
-Briefly disabling cancelability is useful
+Briefly disabling cancellability is useful
 if a thread performs some critical action
 that must not be interrupted by a cancellation request.
-Beware of disabling cancelability for long periods,
+Beware of disabling cancellability for long periods,
 or around operations that may block for long periods,
 since that will render the thread unresponsive to cancellation requests.
-.SS Asynchronous cancelability
-Setting the cancelability type to
+.SS Asynchronous cancellability
+Setting the cancellability type to
 .B PTHREAD_CANCEL_ASYNCHRONOUS
 is rarely useful.
 Since the thread could be canceled at
@@ -185,7 +185,7 @@ be async-cancel-safe.
 In general, other library functions
 can't be safely called from an asynchronously cancelable thread.
 .PP
-One of the few circumstances in which asynchronous cancelability is useful
+One of the few circumstances in which asynchronous cancellability is useful
 is for cancellation of a thread that is in a pure compute-bound loop.
 .SS Portability notes
 The Linux threading implementations permit the
@@ -193,7 +193,7 @@ The Linux threading implementations permit the
 argument of
 .BR pthread_setcancelstate ()
 to be NULL, in which case the information about the previous
-cancelability state is not returned to the caller.
+cancellability state is not returned to the caller.
 Many other implementations also permit a NULL
 .I oldstat
 argument,
diff --git a/man3/pthread_testcancel.3 b/man3/pthread_testcancel.3
index 8dc2d61..88cfa94 100644
--- a/man3/pthread_testcancel.3
+++ b/man3/pthread_testcancel.3
@@ -41,7 +41,7 @@ creates a cancellation point within the calling thread,
 so that a thread that is otherwise executing code that contains
 no cancellation points will respond to a cancellation request.
 .PP
-If cancelability is disabled (using
+If cancellability is disabled (using
 .BR pthread_setcancelstate (3)),
 or no cancellation request is pending,
 then a call to
diff --git a/man7/pthreads.7 b/man7/pthreads.7
index 6f4f6e7..1a347a7 100644
--- a/man7/pthreads.7
+++ b/man7/pthreads.7
@@ -242,7 +242,7 @@ wctomb()
 .in
 .SS Async-cancel-safe functions
 An async-cancel-safe function is one that can be safely called
-in an application where asynchronous cancelability is enabled (see
+in an application where asynchronous cancellability is enabled (see
 .BR pthread_setcancelstate (3)).
 .PP
 Only the following functions are required to be async-cancel-safe by
@@ -258,7 +258,7 @@ pthread_setcanceltype()
 .SS Cancellation points
 POSIX.1 specifies that certain functions must,
 and certain other functions may, be cancellation points.
-If a thread is cancelable, its cancelability type is deferred,
+If a thread is cancelable, its cancellability type is deferred,
 and a cancellation request is pending for the thread,
 then the thread is canceled when it calls a function
 that is a cancellation point.
-- 
2.33.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread
* Re: [patch] pthread_cancel.3, pthread_cleanup_push_defer_np.3, pthread_setcancelstate.3, pthread_testcancel.3, pthreads.7: tfix
  2021-11-13 11:56 [patch] pthread_cancel.3, pthread_cleanup_push_defer_np.3, pthread_setcancelstate.3, pthread_testcancel.3, pthreads.7: tfix Samanta Navarro
@ 2021-11-13 12:40 ` G. Branden Robinson
  2021-11-13 13:00   ` Samanta Navarro
  0 siblings, 1 reply; 6+ messages in thread
From: G. Branden Robinson @ 2021-11-13 12:40 UTC (permalink / raw)
  To: Samanta Navarro; +Cc: linux-man, alx.manpages, mtk.manpages

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

Hi Samanta,

At 2021-11-13T11:56:56+0000, Samanta Navarro wrote:
> Changed cancelability to cancellability.
> 
> Typo found with codespell.

This is a localization issue.  Words like 'travel' and 'cancel' usually
decline to forms with a doubled 'l' in Commonwealth English but retain
an unmodified stem in U.S. English.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [patch] pthread_cancel.3, pthread_cleanup_push_defer_np.3, pthread_setcancelstate.3, pthread_testcancel.3, pthreads.7: tfix
  2021-11-13 12:40 ` G. Branden Robinson
@ 2021-11-13 13:00   ` Samanta Navarro
  2021-11-22 17:09     ` Alejandro Colomar (man-pages)
  0 siblings, 1 reply; 6+ messages in thread
From: Samanta Navarro @ 2021-11-13 13:00 UTC (permalink / raw)
  To: G. Branden Robinson; +Cc: linux-man, alx.manpages, mtk.manpages

On Sat, Nov 13, 2021 at 11:40:17PM +1100, G. Branden Robinson wrote:
> > Changed cancelability to cancellability.
> This is a localization issue.  Words like 'travel' and 'cancel' usually
> decline to forms with a doubled 'l' in Commonwealth English but retain
> an unmodified stem in U.S. English.

You are right. But e.g. pthread_cancel already contains cancellation.
So I think that cancellability would be matching the already existing
style. Or cancellation is also changed to cancelation.

Sincerely,
Samanta

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [patch] pthread_cancel.3, pthread_cleanup_push_defer_np.3, pthread_setcancelstate.3, pthread_testcancel.3, pthreads.7: tfix
  2021-11-13 13:00   ` Samanta Navarro
@ 2021-11-22 17:09     ` Alejandro Colomar (man-pages)
  2021-11-24 11:58       ` Samanta Navarro
  0 siblings, 1 reply; 6+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-11-22 17:09 UTC (permalink / raw)
  To: Samanta Navarro, G. Branden Robinson; +Cc: linux-man, mtk.manpages

Hi Samanta,

On 11/13/21 14:00, Samanta Navarro wrote:
> On Sat, Nov 13, 2021 at 11:40:17PM +1100, G. Branden Robinson wrote:
>>> Changed cancelability to cancellability.
>> This is a localization issue.  Words like 'travel' and 'cancel' usually
>> decline to forms with a doubled 'l' in Commonwealth English but retain
>> an unmodified stem in U.S. English.
> 
> You are right. But e.g. pthread_cancel already contains cancellation.
> So I think that cancellability would be matching the already existing
> style. Or cancellation is also changed to cancelation.

In general (with a few exceptions, see 
<https://lore.kernel.org/linux-man/ffe209ee-809c-10ea-c077-12669ff0f5ab@gmail.com/>), 
we prefer US English.  If you would like to send a patch for 
s/cancellation/cancelation/ I'd like to merge it.

Thanks!
Alex

> 
> Sincerely,
> Samanta
> 

-- 
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [patch] pthread_cancel.3, pthread_cleanup_push_defer_np.3, pthread_setcancelstate.3, pthread_testcancel.3, pthreads.7: tfix
  2021-11-22 17:09     ` Alejandro Colomar (man-pages)
@ 2021-11-24 11:58       ` Samanta Navarro
  2021-11-29 11:59         ` Alejandro Colomar (man-pages)
  0 siblings, 1 reply; 6+ messages in thread
From: Samanta Navarro @ 2021-11-24 11:58 UTC (permalink / raw)
  To: Alejandro Colomar (man-pages)
  Cc: G. Branden Robinson, linux-man, mtk.manpages


Changed cancellation to cancelation.

Signed-off-by: Samanta Navarro <ferivoz@riseup.net>
---
 man3/error.3                         |  2 +-
 man3/fopen.3                         |  2 +-
 man3/getentropy.3                    |  4 +--
 man3/pthread_cancel.3                | 52 ++++++++++++++--------------
 man3/pthread_cleanup_push.3          | 16 ++++-----
 man3/pthread_cleanup_push_defer_np.3 |  8 ++---
 man3/pthread_kill_other_threads_np.3 |  2 +-
 man3/pthread_setcancelstate.3        | 26 +++++++-------
 man3/pthread_testcancel.3            |  8 ++---
 man7/aio.7                           |  4 +--
 man7/attributes.7                    | 42 +++++++++++-----------
 man7/nptl.7                          |  2 +-
 man7/pthreads.7                      | 28 +++++++--------
 man7/signal-safety.7                 |  6 ++--
 14 files changed, 101 insertions(+), 101 deletions(-)

diff --git a/man3/error.3 b/man3/error.3
index 673fe8c..38d0434 100644
--- a/man3/error.3
+++ b/man3/error.3
@@ -149,7 +149,7 @@ used once, it should be safe enough) and, if
 is set nonzero, the internal static variables (not exposed to users)
 used to hold the last printed filename and line number are accessed
 and modified without synchronization; the update is not atomic and it
-occurs before disabling cancellation, so it can be interrupted only after
+occurs before disabling cancelation, so it can be interrupted only after
 one of the two variables is modified.
 After that,
 .BR error_at_line ()
diff --git a/man3/fopen.3 b/man3/fopen.3
index a1d7817..a16af1d 100644
--- a/man3/fopen.3
+++ b/man3/fopen.3
@@ -327,7 +327,7 @@ The GNU C library allows the following extensions for the string specified in
 .BR c " (since glibc 2.3.3)"
 Do not make the open operation,
 or subsequent read and write operations,
-thread cancellation points.
+thread cancelation points.
 This flag is ignored for
 .BR fdopen ().
 .TP
diff --git a/man3/getentropy.3 b/man3/getentropy.3
index dca0a83..4853009 100644
--- a/man3/getentropy.3
+++ b/man3/getentropy.3
@@ -98,9 +98,9 @@ function is implemented using
 .PP
 Whereas the glibc wrapper makes
 .BR getrandom (2)
-a cancellation point,
+a cancelation point,
 .BR getentropy ()
-is not a cancellation point.
+is not a cancelation point.
 .PP
 .BR getentropy ()
 is also declared in
diff --git a/man3/pthread_cancel.3 b/man3/pthread_cancel.3
index 01b7cf0..cf39098 100644
--- a/man3/pthread_cancel.3
+++ b/man3/pthread_cancel.3
@@ -25,7 +25,7 @@
 .\"
 .TH PTHREAD_CANCEL 3 2021-03-22 "Linux" "Linux Programmer's Manual"
 .SH NAME
-pthread_cancel \- send a cancellation request to a thread
+pthread_cancel \- send a cancelation request to a thread
 .SH SYNOPSIS
 .nf
 .B #include <pthread.h>
@@ -37,10 +37,10 @@ Compile and link with \fI\-pthread\fP.
 .SH DESCRIPTION
 The
 .BR pthread_cancel ()
-function sends a cancellation request to the thread
+function sends a cancelation request to the thread
 .IR thread .
 Whether and when the target thread
-reacts to the cancellation request depends on
+reacts to the cancelation request depends on
 two attributes that are under the control of that thread:
 its cancelability
 .I state
@@ -53,13 +53,13 @@ can be
 .I enabled
 (the default for new threads) or
 .IR disabled .
-If a thread has disabled cancellation,
-then a cancellation request remains queued until the thread
-enables cancellation.
-If a thread has enabled cancellation,
-then its cancelability type determines when cancellation occurs.
+If a thread has disabled cancelation,
+then a cancelation request remains queued until the thread
+enables cancelation.
+If a thread has enabled cancelation,
+then its cancelability type determines when cancelation occurs.
 .PP
-A thread's cancellation type, determined by
+A thread's cancelation type, determined by
 .BR pthread_setcanceltype (3),
 may be either
 .IR asynchronous
@@ -69,13 +69,13 @@ or
 Asynchronous cancelability
 means that the thread can be canceled at any time
 (usually immediately, but the system does not guarantee this).
-Deferred cancelability means that cancellation will be delayed until
+Deferred cancelability means that cancelation will be delayed until
 the thread next calls a function that is a
-.IR "cancellation point" .
-A list of functions that are or may be cancellation points is provided in
+.IR "cancelation point" .
+A list of functions that are or may be cancelation points is provided in
 .BR pthreads (7).
 .PP
-When a cancellation requested is acted on, the following steps occur for
+When a cancelation requested is acted on, the following steps occur for
 .IR thread
 (in this order):
 .IP 1. 3
@@ -98,7 +98,7 @@ The above steps happen asynchronously with respect to the
 call;
 the return status of
 .BR pthread_cancel ()
-merely informs the caller whether the cancellation request
+merely informs the caller whether the cancelation request
 was successfully queued.
 .PP
 After a canceled thread has terminated,
@@ -107,7 +107,7 @@ a join with that thread using
 obtains
 .B PTHREAD_CANCELED
 as the thread's exit status.
-(Joining with a thread is the only way to know that cancellation
+(Joining with a thread is the only way to know that cancelation
 has completed.)
 .SH RETURN VALUE
 On success,
@@ -142,7 +142,7 @@ T}	Thread safety	MT-Safe
 .SH CONFORMING TO
 POSIX.1-2001, POSIX.1-2008.
 .SH NOTES
-On Linux, cancellation is implemented using signals.
+On Linux, cancelation is implemented using signals.
 Under the NPTL threading implementation,
 the first real-time signal (i.e., signal 32) is used for this purpose.
 On LinuxThreads, the second real-time signal is used,
@@ -159,9 +159,9 @@ The following shell session shows what happens when we run the program:
 .in +4n
 .EX
 $ ./a.out
-thread_func(): started; cancellation disabled
-main(): sending cancellation request
-thread_func(): about to enable cancellation
+thread_func(): started; cancelation disabled
+main(): sending cancelation request
+thread_func(): about to enable cancelation
 main(): thread was canceled
 .EE
 .in
@@ -182,22 +182,22 @@ thread_func(void *ignored_argument)
 {
     int s;
 
-    /* Disable cancellation for a while, so that we don\(aqt
-       immediately react to a cancellation request. */
+    /* Disable cancelation for a while, so that we don\(aqt
+       immediately react to a cancelation request. */
 
     s = pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
     if (s != 0)
         handle_error_en(s, "pthread_setcancelstate");
 
-    printf("thread_func(): started; cancellation disabled\en");
+    printf("thread_func(): started; cancelation disabled\en");
     sleep(5);
-    printf("thread_func(): about to enable cancellation\en");
+    printf("thread_func(): about to enable cancelation\en");
 
     s = pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
     if (s != 0)
         handle_error_en(s, "pthread_setcancelstate");
 
-    /* sleep() is a cancellation point. */
+    /* sleep() is a cancelation point. */
 
     sleep(1000);        /* Should get canceled while we sleep */
 
@@ -214,7 +214,7 @@ main(void)
     void *res;
     int s;
 
-    /* Start a thread and then send it a cancellation request. */
+    /* Start a thread and then send it a cancelation request. */
 
     s = pthread_create(&thr, NULL, &thread_func, NULL);
     if (s != 0)
@@ -222,7 +222,7 @@ main(void)
 
     sleep(2);           /* Give thread a chance to get started */
 
-    printf("main(): sending cancellation request\en");
+    printf("main(): sending cancelation request\en");
     s = pthread_cancel(thr);
     if (s != 0)
         handle_error_en(s, "pthread_cancel");
diff --git a/man3/pthread_cleanup_push.3 b/man3/pthread_cleanup_push.3
index 7960315..0263248 100644
--- a/man3/pthread_cleanup_push.3
+++ b/man3/pthread_cleanup_push.3
@@ -26,7 +26,7 @@
 .TH PTHREAD_CLEANUP_PUSH 3 2021-03-22 "Linux" "Linux Programmer's Manual"
 .SH NAME
 pthread_cleanup_push, pthread_cleanup_pop \- push and pop
-thread cancellation clean-up handlers
+thread cancelation clean-up handlers
 .SH SYNOPSIS
 .nf
 .B #include <pthread.h>
@@ -38,7 +38,7 @@ Compile and link with \fI\-pthread\fP.
 .fi
 .SH DESCRIPTION
 These functions manipulate the calling thread's stack of
-thread-cancellation clean-up handlers.
+thread-cancelation clean-up handlers.
 A clean-up handler is a function that is automatically executed
 when a thread is canceled (or in various other circumstances
 described below);
@@ -63,7 +63,7 @@ and optionally executes it if
 .I execute
 is nonzero.
 .PP
-A cancellation clean-up handler is popped from the stack
+A cancelation clean-up handler is popped from the stack
 and executed in the following circumstances:
 .IP 1. 3
 When a thread is canceled,
@@ -180,13 +180,13 @@ This loop increments a global variable,
 .IR cnt ,
 once each second.
 Depending on what command-line arguments are supplied,
-the main thread sends the other thread a cancellation request,
+the main thread sends the other thread a cancelation request,
 or sets a global variable that causes the other thread
 to exit its loop and terminate normally (by doing a
 .IR return ).
 .PP
 In the following shell session,
-the main thread sends a cancellation request to the other thread:
+the main thread sends a cancelation request to the other thread:
 .PP
 .in +4n
 .EX
@@ -201,7 +201,7 @@ Thread was canceled; cnt = 0
 .in
 .PP
 From the above, we see that the thread was canceled,
-and that the cancellation clean-up handler was called
+and that the cancelation clean-up handler was called
 and it reset the value of the global variable
 .I cnt
 to 0.
@@ -281,10 +281,10 @@ thread_start(void *arg)
     curr = start = time(NULL);
 
     while (!done) {
-        pthread_testcancel();           /* A cancellation point */
+        pthread_testcancel();           /* A cancelation point */
         if (curr < time(NULL)) {
             curr = time(NULL);
-            printf("cnt = %d\en", cnt);  /* A cancellation point */
+            printf("cnt = %d\en", cnt);  /* A cancelation point */
             cnt++;
         }
     }
diff --git a/man3/pthread_cleanup_push_defer_np.3 b/man3/pthread_cleanup_push_defer_np.3
index c5096d1..27ce08c 100644
--- a/man3/pthread_cleanup_push_defer_np.3
+++ b/man3/pthread_cleanup_push_defer_np.3
@@ -26,7 +26,7 @@
 .TH PTHREAD_CLEANUP_PUSH_DEFER_NP 3 2021-03-22 "Linux" "Linux Programmer's Manual"
 .SH NAME
 pthread_cleanup_push_defer_np, pthread_cleanup_pop_restore_np \- push and pop
-thread cancellation clean-up handlers while saving cancelability type
+thread cancelation clean-up handlers while saving cancelability type
 .SH SYNOPSIS
 .nf
 .B #include <pthread.h>
@@ -59,11 +59,11 @@ Like
 .BR pthread_cleanup_push_defer_np ()
 pushes
 .I routine
-onto the thread's stack of cancellation clean-up handlers.
+onto the thread's stack of cancelation clean-up handlers.
 In addition, it also saves the thread's current cancelability type,
 and sets the cancelability type to "deferred" (see
 .BR pthread_setcanceltype (3));
-this ensures that cancellation clean-up will occur
+this ensures that cancelation clean-up will occur
 even if the thread's cancelability type was "asynchronous"
 before the call.
 .PP
@@ -71,7 +71,7 @@ Like
 .BR pthread_cleanup_pop (3),
 .BR pthread_cleanup_pop_restore_np ()
 pops the top-most clean-up handler from the thread's
-stack of cancellation clean-up handlers.
+stack of cancelation clean-up handlers.
 In addition, it restores the thread's cancelability
 type to its value at the time of the matching
 .BR pthread_cleanup_push_defer_np ().
diff --git a/man3/pthread_kill_other_threads_np.3 b/man3/pthread_kill_other_threads_np.3
index 031f289..ce490af 100644
--- a/man3/pthread_kill_other_threads_np.3
+++ b/man3/pthread_kill_other_threads_np.3
@@ -39,7 +39,7 @@ On that implementation,
 calling this function causes the immediate termination of
 all threads in the application,
 except the calling thread.
-The cancellation state and cancellation type of the
+The cancelation state and cancelation type of the
 to-be-terminated threads are ignored,
 and the cleanup handlers are not called in those threads.
 .\" .SH VERSIONS
diff --git a/man3/pthread_setcancelstate.3 b/man3/pthread_setcancelstate.3
index 56e2acf..e0c7463 100644
--- a/man3/pthread_setcancelstate.3
+++ b/man3/pthread_setcancelstate.3
@@ -54,11 +54,11 @@ The thread is cancelable.
 This is the default cancelability state in all new threads,
 including the initial thread.
 The thread's cancelability type determines when a cancelable thread
-will respond to a cancellation request.
+will respond to a cancelation request.
 .TP
 .B PTHREAD_CANCEL_DISABLE
 The thread is not cancelable.
-If a cancellation request is received,
+If a cancelation request is received,
 it is blocked until cancelability is enabled.
 .PP
 The
@@ -74,21 +74,21 @@ The
 argument must have one of the following values:
 .TP
 .B PTHREAD_CANCEL_DEFERRED
-A cancellation request is deferred until the thread next calls
-a function that is a cancellation point (see
+A cancelation request is deferred until the thread next calls
+a function that is a cancelation point (see
 .BR pthreads (7)).
 This is the default cancelability type in all new threads,
 including the initial thread.
 .IP
-Even with deferred cancellation, a
-cancellation point in an asynchronous signal handler may still
+Even with deferred cancelation, a
+cancelation point in an asynchronous signal handler may still
 be acted upon and the effect is as if it was an asynchronous
-cancellation.
+cancelation.
 .TP
 .B PTHREAD_CANCEL_ASYNCHRONOUS
 The thread can be canceled at any time.
 (Typically,
-it will be canceled immediately upon receiving a cancellation request,
+it will be canceled immediately upon receiving a cancelation request,
 but the system doesn't guarantee this.)
 .PP
 The set-and-get operation performed by each of these functions
@@ -150,10 +150,10 @@ For details of what happens when a thread is canceled, see
 .PP
 Briefly disabling cancelability is useful
 if a thread performs some critical action
-that must not be interrupted by a cancellation request.
+that must not be interrupted by a cancelation request.
 Beware of disabling cancelability for long periods,
 or around operations that may block for long periods,
-since that will render the thread unresponsive to cancellation requests.
+since that will render the thread unresponsive to cancelation requests.
 .SS Asynchronous cancelability
 Setting the cancelability type to
 .B PTHREAD_CANCEL_ASYNCHRONOUS
@@ -165,13 +165,13 @@ time, it cannot safely reserve resources (e.g., allocating memory with
 acquire mutexes, semaphores, or locks, and so on.
 Reserving resources is unsafe because the application has no way of
 knowing what the state of these resources is when the thread is canceled;
-that is, did cancellation occur before the resources were reserved,
+that is, did cancelation occur before the resources were reserved,
 while they were reserved, or after they were released?
 Furthermore, some internal data structures
 (e.g., the linked list of free blocks managed by the
 .BR malloc (3)
 family of functions) may be left in an inconsistent state
-if cancellation occurs in the middle of the function call.
+if cancelation occurs in the middle of the function call.
 Consequently, clean-up handlers cease to be useful.
 .PP
 Functions that can be safely asynchronously canceled are called
@@ -186,7 +186,7 @@ In general, other library functions
 can't be safely called from an asynchronously cancelable thread.
 .PP
 One of the few circumstances in which asynchronous cancelability is useful
-is for cancellation of a thread that is in a pure compute-bound loop.
+is for cancelation of a thread that is in a pure compute-bound loop.
 .SS Portability notes
 The Linux threading implementations permit the
 .I oldstate
diff --git a/man3/pthread_testcancel.3 b/man3/pthread_testcancel.3
index 8dc2d61..42f34a2 100644
--- a/man3/pthread_testcancel.3
+++ b/man3/pthread_testcancel.3
@@ -25,7 +25,7 @@
 .\"
 .TH PTHREAD_TESTCANCEL 3 2021-03-22 "Linux" "Linux Programmer's Manual"
 .SH NAME
-pthread_testcancel \- request delivery of any pending cancellation request
+pthread_testcancel \- request delivery of any pending cancelation request
 .SH SYNOPSIS
 .nf
 .B #include <pthread.h>
@@ -37,13 +37,13 @@ Compile and link with \fI\-pthread\fP.
 .SH DESCRIPTION
 Calling
 .BR pthread_testcancel ()
-creates a cancellation point within the calling thread,
+creates a cancelation point within the calling thread,
 so that a thread that is otherwise executing code that contains
-no cancellation points will respond to a cancellation request.
+no cancelation points will respond to a cancelation request.
 .PP
 If cancelability is disabled (using
 .BR pthread_setcancelstate (3)),
-or no cancellation request is pending,
+or no cancelation request is pending,
 then a call to
 .BR pthread_testcancel ()
 has no effect.
diff --git a/man7/aio.7 b/man7/aio.7
index 72287be..959c354 100644
--- a/man7/aio.7
+++ b/man7/aio.7
@@ -209,7 +209,7 @@ the program retrieves their status using
 The
 .B SIGQUIT
 signal (generated by typing control-\e) causes the program to request
-cancellation of each of the outstanding requests using
+cancelation of each of the outstanding requests using
 .BR aio_cancel (3).
 .PP
 Here is an example of what we might see when running this program.
@@ -371,7 +371,7 @@ main(int argc, char *argv[])
 
             /* On receipt of SIGQUIT, attempt to cancel each of the
                outstanding I/O requests, and display status returned
-               from the cancellation requests. */
+               from the cancelation requests. */
 
             printf("got SIGQUIT; canceling I/O requests: \en");
 
diff --git a/man7/attributes.7 b/man7/attributes.7
index 580ebfe..fdf91e1 100644
--- a/man7/attributes.7
+++ b/man7/attributes.7
@@ -85,7 +85,7 @@ safe for inlining.
 .\" .I AC-Safe
 .\" .I AC-Safe
 .\" or Async-Cancel-Safe functions are safe to call when
-.\" asynchronous cancellation is enabled.
+.\" asynchronous cancelation is enabled.
 .\" AC in AC-Safe stands for Asynchronous Cancellation.
 .\"
 .\" The POSIX standard defines only three functions to be AC-Safe, namely
@@ -99,10 +99,10 @@ safe for inlining.
 .\" This documentation is provided for use
 .\" by the GNU C Library developers.
 .\"
-.\" Just like signal handlers, cancellation cleanup routines must configure
+.\" Just like signal handlers, cancelation cleanup routines must configure
 .\" the floating point environment they require.
 .\" The routines cannot assume a floating point environment,
-.\" particularly when asynchronous cancellation is enabled.
+.\" particularly when asynchronous cancelation is enabled.
 .\" If the configuration of the floating point
 .\" environment cannot be performed atomically then it is also possible that
 .\" the environment encountered is internally inconsistent.
@@ -174,7 +174,7 @@ Other keywords that appear in safety notes are defined in subsequent sections.
 .\" AS-Unsafe features in this section indicate the functions are never safe
 .\" to call when asynchronous signals are enabled.
 .\" AC-Unsafe features
-.\" indicate they are never safe to call when asynchronous cancellation is
+.\" indicate they are never safe to call when asynchronous cancelation is
 .\" .\" enabled.
 .\" There are no MT-Unsafe marks in this section.
 .\" .TP
@@ -190,7 +190,7 @@ Other keywords that appear in safety notes are defined in subsequent sections.
 .\" .I lock
 .\" as an AC-Unsafe feature may, if canceled asynchronously,
 .\" fail to release a lock that would have been released if their execution
-.\" had not been interrupted by asynchronous thread cancellation.
+.\" had not been interrupted by asynchronous thread cancelation.
 .\" Once a lock is left taken,
 .\" attempts to take that lock will block indefinitely.
 .\" .TP
@@ -319,7 +319,7 @@ Other keywords that appear in safety notes are defined in subsequent sections.
 .\" AS-Unsafe, because calling them in signal handlers may interfere with
 .\" timers set in the interrupted code, and AC-Unsafe,
 .\" because there is no safe way to guarantee an earlier timer
-.\" will be reset in case of asynchronous cancellation.
+.\" will be reset in case of asynchronous cancelation.
 .\"
 .\"
 .SS Conditionally safe features
@@ -366,7 +366,7 @@ the function can then be safely called after other threads are started.
 .\" .I init
 .\" as an AS-Safety or AC-Unsafe feature should ensure
 .\" the initialization is performed
-.\" before configuring signal handlers or enabling cancellation,
+.\" before configuring signal handlers or enabling cancelation,
 .\" so that the AS-Safety and AC-Safety issues related with
 .\" .I libc_once
 .\" do not arise.
@@ -565,16 +565,16 @@ blocking that signal before the call and resetting its
 handler afterwards is recommended.
 .\"
 .\" There is no safe way to guarantee the original signal handler is
-.\" restored in case of asynchronous cancellation,
+.\" restored in case of asynchronous cancelation,
 .\" therefore so-marked functions are also AC-Unsafe.
 .\"
-.\" .\" fixme: at least deferred cancellation should get it right, and would
+.\" .\" fixme: at least deferred cancelation should get it right, and would
 .\" .\" obviate the restoring bit below, and the qualifier above.
 .\"
 .\" Besides the measures recommended to work around the
 .\" MT-Safety and AS-Safety problem,
-.\" in order to avert the cancellation problem,
-.\" disabling asynchronous cancellation
+.\" in order to avert the cancelation problem,
+.\" disabling asynchronous cancelation
 .\" .I and
 .\" installing a cleanup handler to restore the signal to the desired state
 .\" and to release the mutex are recommended.
@@ -616,13 +616,13 @@ even if referenced by different file descriptors.
 .\" restore terminal settings to their original state,
 .\" after temporarily changing them, but they may fail to do so if canceled.
 .\"
-.\" .\" fixme: at least deferred cancellation should get it right, and would
+.\" .\" fixme: at least deferred cancelation should get it right, and would
 .\" .\" obviate the restoring bit below, and the qualifier above.
 .\"
 .\" Besides the measures recommended to work around the
 .\" MT-Safety and AS-Safety problem,
-.\" in order to avert the cancellation problem,
-.\" disabling asynchronous cancellation
+.\" in order to avert the cancelation problem,
+.\" disabling asynchronous cancelation
 .\" .I and
 .\" installing a cleanup handler to
 .\" restore the terminal settings to the original state and to release the
@@ -733,7 +733,7 @@ which makes the former safe.
 .\" Functions annotated with
 .\" .I fd
 .\" as an AC-Safety issue may leak file
-.\" descriptors if asynchronous thread cancellation interrupts their
+.\" descriptors if asynchronous thread cancelation interrupts their
 .\" execution.
 .\"
 .\" Functions that allocate or deallocate file descriptors will generally be
@@ -755,7 +755,7 @@ which makes the former safe.
 .\" reallocated by another thread or signal handler.
 .\"
 .\" Such leaks could be internally avoided, with some performance penalty,
-.\" by temporarily disabling asynchronous thread cancellation.
+.\" by temporarily disabling asynchronous thread cancelation.
 .\" However,
 .\" since callers of allocation or deallocation functions would have to do
 .\" this themselves, to avoid the same sort of leak in their own layer,
@@ -768,26 +768,26 @@ which makes the former safe.
 .\" However, cumulative effects of such leaks may pose a
 .\" problem for some programs.
 .\" If this is the case,
-.\" suspending asynchronous cancellation for the duration of calls
+.\" suspending asynchronous cancelation for the duration of calls
 .\" to such functions is recommended.
 .\" .TP
 .\" .I mem
 .\" Functions annotated with
 .\" .I mem
 .\" as an AC-Safety issue may leak
-.\" memory if asynchronous thread cancellation interrupts their execution.
+.\" memory if asynchronous thread cancelation interrupts their execution.
 .\"
 .\" The problem is similar to that of file descriptors: there is no atomic
 .\" interface to allocate memory and store its address in the argument to a
 .\" cleanup handler,
 .\" or to release it and remove its address from that argument,
-.\" without at least temporarily disabling asynchronous cancellation,
+.\" without at least temporarily disabling asynchronous cancelation,
 .\" which these functions do not do.
 .\"
 .\" This remark does not by itself cause a function to be regarded as
 .\" generally AC-Unsafe.
 .\" However, cumulative effects of such leaks may be
-.\" severe enough for some programs that disabling asynchronous cancellation
+.\" severe enough for some programs that disabling asynchronous cancelation
 .\" for the duration of calls to such functions may be required.
 .TP
 .I cwd
@@ -796,7 +796,7 @@ Functions marked with
 as an MT-Safety issue may temporarily
 change the current working directory during their execution,
 which may cause relative pathnames to be resolved in unexpected ways in
-other threads or within asynchronous signal or cancellation handlers.
+other threads or within asynchronous signal or cancelation handlers.
 .IP
 This is not enough of a reason to mark so-marked functions as MT-Unsafe,
 .\" or AS-Unsafe,
diff --git a/man7/nptl.7 b/man7/nptl.7
index 0133c0a..ea17940 100644
--- a/man7/nptl.7
+++ b/man7/nptl.7
@@ -34,7 +34,7 @@ Linux systems.
 .SS NPTL and signals
 NPTL makes internal use of the first two real-time signals
 (signal numbers 32 and 33).
-One of these signals is used to support thread cancellation and POSIX timers
+One of these signals is used to support thread cancelation and POSIX timers
 (see
 .BR timer_create (2));
 the other is used as part of a mechanism that ensures all threads in
diff --git a/man7/pthreads.7 b/man7/pthreads.7
index 6f4f6e7..380aeb2 100644
--- a/man7/pthreads.7
+++ b/man7/pthreads.7
@@ -257,17 +257,17 @@ pthread_setcanceltype()
 .in
 .SS Cancellation points
 POSIX.1 specifies that certain functions must,
-and certain other functions may, be cancellation points.
+and certain other functions may, be cancelation points.
 If a thread is cancelable, its cancelability type is deferred,
-and a cancellation request is pending for the thread,
+and a cancelation request is pending for the thread,
 then the thread is canceled when it calls a function
-that is a cancellation point.
+that is a cancelation point.
 .PP
-The following functions are required to be cancellation points by
+The following functions are required to be cancelation points by
 POSIX.1-2001 and/or POSIX.1-2008:
 .PP
 .\" FIXME
-.\" Document the list of all functions that are cancellation points in glibc
+.\" Document the list of all functions that are cancelation points in glibc
 .in +4n
 .EX
 accept()
@@ -331,7 +331,7 @@ writev()
 .EE
 .in
 .PP
-The following functions may be cancellation points according to
+The following functions may be cancelation points according to
 POSIX.1-2001 and/or POSIX.1-2008:
 .PP
 .in +4n
@@ -567,23 +567,23 @@ wscanf()
 .in
 .PP
 An implementation may also mark other functions
-not specified in the standard as cancellation points.
+not specified in the standard as cancelation points.
 In particular, an implementation is likely to mark
-any nonstandard function that may block as a cancellation point.
+any nonstandard function that may block as a cancelation point.
 (This includes most functions that can touch files.)
 .PP
 It should be noted that even if an application is not using
-asynchronous cancellation, that calling a function from the above list
+asynchronous cancelation, that calling a function from the above list
 from an asynchronous signal handler may cause the equivalent of
-asynchronous cancellation.
+asynchronous cancelation.
 The underlying user code may not expect
-asynchronous cancellation and the state of the user data may become
+asynchronous cancelation and the state of the user data may become
 inconsistent.
 Therefore signals should be used with caution when
-entering a region of deferred cancellation.
-.\" So, scanning "cancellation point" comments in the glibc 2.8 header
+entering a region of deferred cancelation.
+.\" So, scanning "cancelation point" comments in the glibc 2.8 header
 .\" files, it looks as though at least the following nonstandard
-.\" functions are cancellation points:
+.\" functions are cancelation points:
 .\" endnetgrent
 .\" endspent
 .\" epoll_pwait
diff --git a/man7/signal-safety.7 b/man7/signal-safety.7
index 9e8cd3f..b0108c8 100644
--- a/man7/signal-safety.7
+++ b/man7/signal-safety.7
@@ -322,9 +322,9 @@ is likely to remove
 from the list of async-signal-safe functions.
 .\"
 .IP * 3
-Asynchronous signal handlers that call functions which are cancellation
-points and nest over regions of deferred cancellation may trigger
-cancellation whose behavior is as if asynchronous cancellation had
+Asynchronous signal handlers that call functions which are cancelation
+points and nest over regions of deferred cancelation may trigger
+cancelation whose behavior is as if asynchronous cancelation had
 occurred and may cause application state to become inconsistent.
 .\"
 .SS errno
-- 
2.34.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread
* Re: [patch] pthread_cancel.3, pthread_cleanup_push_defer_np.3, pthread_setcancelstate.3, pthread_testcancel.3, pthreads.7: tfix
  2021-11-24 11:58       ` Samanta Navarro
@ 2021-11-29 11:59         ` Alejandro Colomar (man-pages)
  0 siblings, 0 replies; 6+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-11-29 11:59 UTC (permalink / raw)
  To: Samanta Navarro; +Cc: G. Branden Robinson, linux-man, mtk.manpages

Hi Samanta,

On 11/24/21 12:58, Samanta Navarro wrote:
> 
> Changed cancellation to cancelation.
> 
> Signed-off-by: Samanta Navarro <ferivoz@riseup.net>

Patch applied.
Thanks!

Alex

> ---
>   man3/error.3                         |  2 +-
>   man3/fopen.3                         |  2 +-
>   man3/getentropy.3                    |  4 +--
>   man3/pthread_cancel.3                | 52 ++++++++++++++--------------
>   man3/pthread_cleanup_push.3          | 16 ++++-----
>   man3/pthread_cleanup_push_defer_np.3 |  8 ++---
>   man3/pthread_kill_other_threads_np.3 |  2 +-
>   man3/pthread_setcancelstate.3        | 26 +++++++-------
>   man3/pthread_testcancel.3            |  8 ++---
>   man7/aio.7                           |  4 +--
>   man7/attributes.7                    | 42 +++++++++++-----------
>   man7/nptl.7                          |  2 +-
>   man7/pthreads.7                      | 28 +++++++--------
>   man7/signal-safety.7                 |  6 ++--
>   14 files changed, 101 insertions(+), 101 deletions(-)
> 
> diff --git a/man3/error.3 b/man3/error.3
> index 673fe8c..38d0434 100644
> --- a/man3/error.3
> +++ b/man3/error.3
> @@ -149,7 +149,7 @@ used once, it should be safe enough) and, if
>   is set nonzero, the internal static variables (not exposed to users)
>   used to hold the last printed filename and line number are accessed
>   and modified without synchronization; the update is not atomic and it
> -occurs before disabling cancellation, so it can be interrupted only after
> +occurs before disabling cancelation, so it can be interrupted only after
>   one of the two variables is modified.
>   After that,
>   .BR error_at_line ()
> diff --git a/man3/fopen.3 b/man3/fopen.3
> index a1d7817..a16af1d 100644
> --- a/man3/fopen.3
> +++ b/man3/fopen.3
> @@ -327,7 +327,7 @@ The GNU C library allows the following extensions for the string specified in
>   .BR c " (since glibc 2.3.3)"
>   Do not make the open operation,
>   or subsequent read and write operations,
> -thread cancellation points.
> +thread cancelation points.
>   This flag is ignored for
>   .BR fdopen ().
>   .TP
> diff --git a/man3/getentropy.3 b/man3/getentropy.3
> index dca0a83..4853009 100644
> --- a/man3/getentropy.3
> +++ b/man3/getentropy.3
> @@ -98,9 +98,9 @@ function is implemented using
>   .PP
>   Whereas the glibc wrapper makes
>   .BR getrandom (2)
> -a cancellation point,
> +a cancelation point,
>   .BR getentropy ()
> -is not a cancellation point.
> +is not a cancelation point.
>   .PP
>   .BR getentropy ()
>   is also declared in
> diff --git a/man3/pthread_cancel.3 b/man3/pthread_cancel.3
> index 01b7cf0..cf39098 100644
> --- a/man3/pthread_cancel.3
> +++ b/man3/pthread_cancel.3
> @@ -25,7 +25,7 @@
>   .\"
>   .TH PTHREAD_CANCEL 3 2021-03-22 "Linux" "Linux Programmer's Manual"
>   .SH NAME
> -pthread_cancel \- send a cancellation request to a thread
> +pthread_cancel \- send a cancelation request to a thread
>   .SH SYNOPSIS
>   .nf
>   .B #include <pthread.h>
> @@ -37,10 +37,10 @@ Compile and link with \fI\-pthread\fP.
>   .SH DESCRIPTION
>   The
>   .BR pthread_cancel ()
> -function sends a cancellation request to the thread
> +function sends a cancelation request to the thread
>   .IR thread .
>   Whether and when the target thread
> -reacts to the cancellation request depends on
> +reacts to the cancelation request depends on
>   two attributes that are under the control of that thread:
>   its cancelability
>   .I state
> @@ -53,13 +53,13 @@ can be
>   .I enabled
>   (the default for new threads) or
>   .IR disabled .
> -If a thread has disabled cancellation,
> -then a cancellation request remains queued until the thread
> -enables cancellation.
> -If a thread has enabled cancellation,
> -then its cancelability type determines when cancellation occurs.
> +If a thread has disabled cancelation,
> +then a cancelation request remains queued until the thread
> +enables cancelation.
> +If a thread has enabled cancelation,
> +then its cancelability type determines when cancelation occurs.
>   .PP
> -A thread's cancellation type, determined by
> +A thread's cancelation type, determined by
>   .BR pthread_setcanceltype (3),
>   may be either
>   .IR asynchronous
> @@ -69,13 +69,13 @@ or
>   Asynchronous cancelability
>   means that the thread can be canceled at any time
>   (usually immediately, but the system does not guarantee this).
> -Deferred cancelability means that cancellation will be delayed until
> +Deferred cancelability means that cancelation will be delayed until
>   the thread next calls a function that is a
> -.IR "cancellation point" .
> -A list of functions that are or may be cancellation points is provided in
> +.IR "cancelation point" .
> +A list of functions that are or may be cancelation points is provided in
>   .BR pthreads (7).
>   .PP
> -When a cancellation requested is acted on, the following steps occur for
> +When a cancelation requested is acted on, the following steps occur for
>   .IR thread
>   (in this order):
>   .IP 1. 3
> @@ -98,7 +98,7 @@ The above steps happen asynchronously with respect to the
>   call;
>   the return status of
>   .BR pthread_cancel ()
> -merely informs the caller whether the cancellation request
> +merely informs the caller whether the cancelation request
>   was successfully queued.
>   .PP
>   After a canceled thread has terminated,
> @@ -107,7 +107,7 @@ a join with that thread using
>   obtains
>   .B PTHREAD_CANCELED
>   as the thread's exit status.
> -(Joining with a thread is the only way to know that cancellation
> +(Joining with a thread is the only way to know that cancelation
>   has completed.)
>   .SH RETURN VALUE
>   On success,
> @@ -142,7 +142,7 @@ T}	Thread safety	MT-Safe
>   .SH CONFORMING TO
>   POSIX.1-2001, POSIX.1-2008.
>   .SH NOTES
> -On Linux, cancellation is implemented using signals.
> +On Linux, cancelation is implemented using signals.
>   Under the NPTL threading implementation,
>   the first real-time signal (i.e., signal 32) is used for this purpose.
>   On LinuxThreads, the second real-time signal is used,
> @@ -159,9 +159,9 @@ The following shell session shows what happens when we run the program:
>   .in +4n
>   .EX
>   $ ./a.out
> -thread_func(): started; cancellation disabled
> -main(): sending cancellation request
> -thread_func(): about to enable cancellation
> +thread_func(): started; cancelation disabled
> +main(): sending cancelation request
> +thread_func(): about to enable cancelation
>   main(): thread was canceled
>   .EE
>   .in
> @@ -182,22 +182,22 @@ thread_func(void *ignored_argument)
>   {
>       int s;
>   
> -    /* Disable cancellation for a while, so that we don\(aqt
> -       immediately react to a cancellation request. */
> +    /* Disable cancelation for a while, so that we don\(aqt
> +       immediately react to a cancelation request. */
>   
>       s = pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
>       if (s != 0)
>           handle_error_en(s, "pthread_setcancelstate");
>   
> -    printf("thread_func(): started; cancellation disabled\en");
> +    printf("thread_func(): started; cancelation disabled\en");
>       sleep(5);
> -    printf("thread_func(): about to enable cancellation\en");
> +    printf("thread_func(): about to enable cancelation\en");
>   
>       s = pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
>       if (s != 0)
>           handle_error_en(s, "pthread_setcancelstate");
>   
> -    /* sleep() is a cancellation point. */
> +    /* sleep() is a cancelation point. */
>   
>       sleep(1000);        /* Should get canceled while we sleep */
>   
> @@ -214,7 +214,7 @@ main(void)
>       void *res;
>       int s;
>   
> -    /* Start a thread and then send it a cancellation request. */
> +    /* Start a thread and then send it a cancelation request. */
>   
>       s = pthread_create(&thr, NULL, &thread_func, NULL);
>       if (s != 0)
> @@ -222,7 +222,7 @@ main(void)
>   
>       sleep(2);           /* Give thread a chance to get started */
>   
> -    printf("main(): sending cancellation request\en");
> +    printf("main(): sending cancelation request\en");
>       s = pthread_cancel(thr);
>       if (s != 0)
>           handle_error_en(s, "pthread_cancel");
> diff --git a/man3/pthread_cleanup_push.3 b/man3/pthread_cleanup_push.3
> index 7960315..0263248 100644
> --- a/man3/pthread_cleanup_push.3
> +++ b/man3/pthread_cleanup_push.3
> @@ -26,7 +26,7 @@
>   .TH PTHREAD_CLEANUP_PUSH 3 2021-03-22 "Linux" "Linux Programmer's Manual"
>   .SH NAME
>   pthread_cleanup_push, pthread_cleanup_pop \- push and pop
> -thread cancellation clean-up handlers
> +thread cancelation clean-up handlers
>   .SH SYNOPSIS
>   .nf
>   .B #include <pthread.h>
> @@ -38,7 +38,7 @@ Compile and link with \fI\-pthread\fP.
>   .fi
>   .SH DESCRIPTION
>   These functions manipulate the calling thread's stack of
> -thread-cancellation clean-up handlers.
> +thread-cancelation clean-up handlers.
>   A clean-up handler is a function that is automatically executed
>   when a thread is canceled (or in various other circumstances
>   described below);
> @@ -63,7 +63,7 @@ and optionally executes it if
>   .I execute
>   is nonzero.
>   .PP
> -A cancellation clean-up handler is popped from the stack
> +A cancelation clean-up handler is popped from the stack
>   and executed in the following circumstances:
>   .IP 1. 3
>   When a thread is canceled,
> @@ -180,13 +180,13 @@ This loop increments a global variable,
>   .IR cnt ,
>   once each second.
>   Depending on what command-line arguments are supplied,
> -the main thread sends the other thread a cancellation request,
> +the main thread sends the other thread a cancelation request,
>   or sets a global variable that causes the other thread
>   to exit its loop and terminate normally (by doing a
>   .IR return ).
>   .PP
>   In the following shell session,
> -the main thread sends a cancellation request to the other thread:
> +the main thread sends a cancelation request to the other thread:
>   .PP
>   .in +4n
>   .EX
> @@ -201,7 +201,7 @@ Thread was canceled; cnt = 0
>   .in
>   .PP
>   From the above, we see that the thread was canceled,
> -and that the cancellation clean-up handler was called
> +and that the cancelation clean-up handler was called
>   and it reset the value of the global variable
>   .I cnt
>   to 0.
> @@ -281,10 +281,10 @@ thread_start(void *arg)
>       curr = start = time(NULL);
>   
>       while (!done) {
> -        pthread_testcancel();           /* A cancellation point */
> +        pthread_testcancel();           /* A cancelation point */
>           if (curr < time(NULL)) {
>               curr = time(NULL);
> -            printf("cnt = %d\en", cnt);  /* A cancellation point */
> +            printf("cnt = %d\en", cnt);  /* A cancelation point */
>               cnt++;
>           }
>       }
> diff --git a/man3/pthread_cleanup_push_defer_np.3 b/man3/pthread_cleanup_push_defer_np.3
> index c5096d1..27ce08c 100644
> --- a/man3/pthread_cleanup_push_defer_np.3
> +++ b/man3/pthread_cleanup_push_defer_np.3
> @@ -26,7 +26,7 @@
>   .TH PTHREAD_CLEANUP_PUSH_DEFER_NP 3 2021-03-22 "Linux" "Linux Programmer's Manual"
>   .SH NAME
>   pthread_cleanup_push_defer_np, pthread_cleanup_pop_restore_np \- push and pop
> -thread cancellation clean-up handlers while saving cancelability type
> +thread cancelation clean-up handlers while saving cancelability type
>   .SH SYNOPSIS
>   .nf
>   .B #include <pthread.h>
> @@ -59,11 +59,11 @@ Like
>   .BR pthread_cleanup_push_defer_np ()
>   pushes
>   .I routine
> -onto the thread's stack of cancellation clean-up handlers.
> +onto the thread's stack of cancelation clean-up handlers.
>   In addition, it also saves the thread's current cancelability type,
>   and sets the cancelability type to "deferred" (see
>   .BR pthread_setcanceltype (3));
> -this ensures that cancellation clean-up will occur
> +this ensures that cancelation clean-up will occur
>   even if the thread's cancelability type was "asynchronous"
>   before the call.
>   .PP
> @@ -71,7 +71,7 @@ Like
>   .BR pthread_cleanup_pop (3),
>   .BR pthread_cleanup_pop_restore_np ()
>   pops the top-most clean-up handler from the thread's
> -stack of cancellation clean-up handlers.
> +stack of cancelation clean-up handlers.
>   In addition, it restores the thread's cancelability
>   type to its value at the time of the matching
>   .BR pthread_cleanup_push_defer_np ().
> diff --git a/man3/pthread_kill_other_threads_np.3 b/man3/pthread_kill_other_threads_np.3
> index 031f289..ce490af 100644
> --- a/man3/pthread_kill_other_threads_np.3
> +++ b/man3/pthread_kill_other_threads_np.3
> @@ -39,7 +39,7 @@ On that implementation,
>   calling this function causes the immediate termination of
>   all threads in the application,
>   except the calling thread.
> -The cancellation state and cancellation type of the
> +The cancelation state and cancelation type of the
>   to-be-terminated threads are ignored,
>   and the cleanup handlers are not called in those threads.
>   .\" .SH VERSIONS
> diff --git a/man3/pthread_setcancelstate.3 b/man3/pthread_setcancelstate.3
> index 56e2acf..e0c7463 100644
> --- a/man3/pthread_setcancelstate.3
> +++ b/man3/pthread_setcancelstate.3
> @@ -54,11 +54,11 @@ The thread is cancelable.
>   This is the default cancelability state in all new threads,
>   including the initial thread.
>   The thread's cancelability type determines when a cancelable thread
> -will respond to a cancellation request.
> +will respond to a cancelation request.
>   .TP
>   .B PTHREAD_CANCEL_DISABLE
>   The thread is not cancelable.
> -If a cancellation request is received,
> +If a cancelation request is received,
>   it is blocked until cancelability is enabled.
>   .PP
>   The
> @@ -74,21 +74,21 @@ The
>   argument must have one of the following values:
>   .TP
>   .B PTHREAD_CANCEL_DEFERRED
> -A cancellation request is deferred until the thread next calls
> -a function that is a cancellation point (see
> +A cancelation request is deferred until the thread next calls
> +a function that is a cancelation point (see
>   .BR pthreads (7)).
>   This is the default cancelability type in all new threads,
>   including the initial thread.
>   .IP
> -Even with deferred cancellation, a
> -cancellation point in an asynchronous signal handler may still
> +Even with deferred cancelation, a
> +cancelation point in an asynchronous signal handler may still
>   be acted upon and the effect is as if it was an asynchronous
> -cancellation.
> +cancelation.
>   .TP
>   .B PTHREAD_CANCEL_ASYNCHRONOUS
>   The thread can be canceled at any time.
>   (Typically,
> -it will be canceled immediately upon receiving a cancellation request,
> +it will be canceled immediately upon receiving a cancelation request,
>   but the system doesn't guarantee this.)
>   .PP
>   The set-and-get operation performed by each of these functions
> @@ -150,10 +150,10 @@ For details of what happens when a thread is canceled, see
>   .PP
>   Briefly disabling cancelability is useful
>   if a thread performs some critical action
> -that must not be interrupted by a cancellation request.
> +that must not be interrupted by a cancelation request.
>   Beware of disabling cancelability for long periods,
>   or around operations that may block for long periods,
> -since that will render the thread unresponsive to cancellation requests.
> +since that will render the thread unresponsive to cancelation requests.
>   .SS Asynchronous cancelability
>   Setting the cancelability type to
>   .B PTHREAD_CANCEL_ASYNCHRONOUS
> @@ -165,13 +165,13 @@ time, it cannot safely reserve resources (e.g., allocating memory with
>   acquire mutexes, semaphores, or locks, and so on.
>   Reserving resources is unsafe because the application has no way of
>   knowing what the state of these resources is when the thread is canceled;
> -that is, did cancellation occur before the resources were reserved,
> +that is, did cancelation occur before the resources were reserved,
>   while they were reserved, or after they were released?
>   Furthermore, some internal data structures
>   (e.g., the linked list of free blocks managed by the
>   .BR malloc (3)
>   family of functions) may be left in an inconsistent state
> -if cancellation occurs in the middle of the function call.
> +if cancelation occurs in the middle of the function call.
>   Consequently, clean-up handlers cease to be useful.
>   .PP
>   Functions that can be safely asynchronously canceled are called
> @@ -186,7 +186,7 @@ In general, other library functions
>   can't be safely called from an asynchronously cancelable thread.
>   .PP
>   One of the few circumstances in which asynchronous cancelability is useful
> -is for cancellation of a thread that is in a pure compute-bound loop.
> +is for cancelation of a thread that is in a pure compute-bound loop.
>   .SS Portability notes
>   The Linux threading implementations permit the
>   .I oldstate
> diff --git a/man3/pthread_testcancel.3 b/man3/pthread_testcancel.3
> index 8dc2d61..42f34a2 100644
> --- a/man3/pthread_testcancel.3
> +++ b/man3/pthread_testcancel.3
> @@ -25,7 +25,7 @@
>   .\"
>   .TH PTHREAD_TESTCANCEL 3 2021-03-22 "Linux" "Linux Programmer's Manual"
>   .SH NAME
> -pthread_testcancel \- request delivery of any pending cancellation request
> +pthread_testcancel \- request delivery of any pending cancelation request
>   .SH SYNOPSIS
>   .nf
>   .B #include <pthread.h>
> @@ -37,13 +37,13 @@ Compile and link with \fI\-pthread\fP.
>   .SH DESCRIPTION
>   Calling
>   .BR pthread_testcancel ()
> -creates a cancellation point within the calling thread,
> +creates a cancelation point within the calling thread,
>   so that a thread that is otherwise executing code that contains
> -no cancellation points will respond to a cancellation request.
> +no cancelation points will respond to a cancelation request.
>   .PP
>   If cancelability is disabled (using
>   .BR pthread_setcancelstate (3)),
> -or no cancellation request is pending,
> +or no cancelation request is pending,
>   then a call to
>   .BR pthread_testcancel ()
>   has no effect.
> diff --git a/man7/aio.7 b/man7/aio.7
> index 72287be..959c354 100644
> --- a/man7/aio.7
> +++ b/man7/aio.7
> @@ -209,7 +209,7 @@ the program retrieves their status using
>   The
>   .B SIGQUIT
>   signal (generated by typing control-\e) causes the program to request
> -cancellation of each of the outstanding requests using
> +cancelation of each of the outstanding requests using
>   .BR aio_cancel (3).
>   .PP
>   Here is an example of what we might see when running this program.
> @@ -371,7 +371,7 @@ main(int argc, char *argv[])
>   
>               /* On receipt of SIGQUIT, attempt to cancel each of the
>                  outstanding I/O requests, and display status returned
> -               from the cancellation requests. */
> +               from the cancelation requests. */
>   
>               printf("got SIGQUIT; canceling I/O requests: \en");
>   
> diff --git a/man7/attributes.7 b/man7/attributes.7
> index 580ebfe..fdf91e1 100644
> --- a/man7/attributes.7
> +++ b/man7/attributes.7
> @@ -85,7 +85,7 @@ safe for inlining.
>   .\" .I AC-Safe
>   .\" .I AC-Safe
>   .\" or Async-Cancel-Safe functions are safe to call when
> -.\" asynchronous cancellation is enabled.
> +.\" asynchronous cancelation is enabled.
>   .\" AC in AC-Safe stands for Asynchronous Cancellation.
>   .\"
>   .\" The POSIX standard defines only three functions to be AC-Safe, namely
> @@ -99,10 +99,10 @@ safe for inlining.
>   .\" This documentation is provided for use
>   .\" by the GNU C Library developers.
>   .\"
> -.\" Just like signal handlers, cancellation cleanup routines must configure
> +.\" Just like signal handlers, cancelation cleanup routines must configure
>   .\" the floating point environment they require.
>   .\" The routines cannot assume a floating point environment,
> -.\" particularly when asynchronous cancellation is enabled.
> +.\" particularly when asynchronous cancelation is enabled.
>   .\" If the configuration of the floating point
>   .\" environment cannot be performed atomically then it is also possible that
>   .\" the environment encountered is internally inconsistent.
> @@ -174,7 +174,7 @@ Other keywords that appear in safety notes are defined in subsequent sections.
>   .\" AS-Unsafe features in this section indicate the functions are never safe
>   .\" to call when asynchronous signals are enabled.
>   .\" AC-Unsafe features
> -.\" indicate they are never safe to call when asynchronous cancellation is
> +.\" indicate they are never safe to call when asynchronous cancelation is
>   .\" .\" enabled.
>   .\" There are no MT-Unsafe marks in this section.
>   .\" .TP
> @@ -190,7 +190,7 @@ Other keywords that appear in safety notes are defined in subsequent sections.
>   .\" .I lock
>   .\" as an AC-Unsafe feature may, if canceled asynchronously,
>   .\" fail to release a lock that would have been released if their execution
> -.\" had not been interrupted by asynchronous thread cancellation.
> +.\" had not been interrupted by asynchronous thread cancelation.
>   .\" Once a lock is left taken,
>   .\" attempts to take that lock will block indefinitely.
>   .\" .TP
> @@ -319,7 +319,7 @@ Other keywords that appear in safety notes are defined in subsequent sections.
>   .\" AS-Unsafe, because calling them in signal handlers may interfere with
>   .\" timers set in the interrupted code, and AC-Unsafe,
>   .\" because there is no safe way to guarantee an earlier timer
> -.\" will be reset in case of asynchronous cancellation.
> +.\" will be reset in case of asynchronous cancelation.
>   .\"
>   .\"
>   .SS Conditionally safe features
> @@ -366,7 +366,7 @@ the function can then be safely called after other threads are started.
>   .\" .I init
>   .\" as an AS-Safety or AC-Unsafe feature should ensure
>   .\" the initialization is performed
> -.\" before configuring signal handlers or enabling cancellation,
> +.\" before configuring signal handlers or enabling cancelation,
>   .\" so that the AS-Safety and AC-Safety issues related with
>   .\" .I libc_once
>   .\" do not arise.
> @@ -565,16 +565,16 @@ blocking that signal before the call and resetting its
>   handler afterwards is recommended.
>   .\"
>   .\" There is no safe way to guarantee the original signal handler is
> -.\" restored in case of asynchronous cancellation,
> +.\" restored in case of asynchronous cancelation,
>   .\" therefore so-marked functions are also AC-Unsafe.
>   .\"
> -.\" .\" fixme: at least deferred cancellation should get it right, and would
> +.\" .\" fixme: at least deferred cancelation should get it right, and would
>   .\" .\" obviate the restoring bit below, and the qualifier above.
>   .\"
>   .\" Besides the measures recommended to work around the
>   .\" MT-Safety and AS-Safety problem,
> -.\" in order to avert the cancellation problem,
> -.\" disabling asynchronous cancellation
> +.\" in order to avert the cancelation problem,
> +.\" disabling asynchronous cancelation
>   .\" .I and
>   .\" installing a cleanup handler to restore the signal to the desired state
>   .\" and to release the mutex are recommended.
> @@ -616,13 +616,13 @@ even if referenced by different file descriptors.
>   .\" restore terminal settings to their original state,
>   .\" after temporarily changing them, but they may fail to do so if canceled.
>   .\"
> -.\" .\" fixme: at least deferred cancellation should get it right, and would
> +.\" .\" fixme: at least deferred cancelation should get it right, and would
>   .\" .\" obviate the restoring bit below, and the qualifier above.
>   .\"
>   .\" Besides the measures recommended to work around the
>   .\" MT-Safety and AS-Safety problem,
> -.\" in order to avert the cancellation problem,
> -.\" disabling asynchronous cancellation
> +.\" in order to avert the cancelation problem,
> +.\" disabling asynchronous cancelation
>   .\" .I and
>   .\" installing a cleanup handler to
>   .\" restore the terminal settings to the original state and to release the
> @@ -733,7 +733,7 @@ which makes the former safe.
>   .\" Functions annotated with
>   .\" .I fd
>   .\" as an AC-Safety issue may leak file
> -.\" descriptors if asynchronous thread cancellation interrupts their
> +.\" descriptors if asynchronous thread cancelation interrupts their
>   .\" execution.
>   .\"
>   .\" Functions that allocate or deallocate file descriptors will generally be
> @@ -755,7 +755,7 @@ which makes the former safe.
>   .\" reallocated by another thread or signal handler.
>   .\"
>   .\" Such leaks could be internally avoided, with some performance penalty,
> -.\" by temporarily disabling asynchronous thread cancellation.
> +.\" by temporarily disabling asynchronous thread cancelation.
>   .\" However,
>   .\" since callers of allocation or deallocation functions would have to do
>   .\" this themselves, to avoid the same sort of leak in their own layer,
> @@ -768,26 +768,26 @@ which makes the former safe.
>   .\" However, cumulative effects of such leaks may pose a
>   .\" problem for some programs.
>   .\" If this is the case,
> -.\" suspending asynchronous cancellation for the duration of calls
> +.\" suspending asynchronous cancelation for the duration of calls
>   .\" to such functions is recommended.
>   .\" .TP
>   .\" .I mem
>   .\" Functions annotated with
>   .\" .I mem
>   .\" as an AC-Safety issue may leak
> -.\" memory if asynchronous thread cancellation interrupts their execution.
> +.\" memory if asynchronous thread cancelation interrupts their execution.
>   .\"
>   .\" The problem is similar to that of file descriptors: there is no atomic
>   .\" interface to allocate memory and store its address in the argument to a
>   .\" cleanup handler,
>   .\" or to release it and remove its address from that argument,
> -.\" without at least temporarily disabling asynchronous cancellation,
> +.\" without at least temporarily disabling asynchronous cancelation,
>   .\" which these functions do not do.
>   .\"
>   .\" This remark does not by itself cause a function to be regarded as
>   .\" generally AC-Unsafe.
>   .\" However, cumulative effects of such leaks may be
> -.\" severe enough for some programs that disabling asynchronous cancellation
> +.\" severe enough for some programs that disabling asynchronous cancelation
>   .\" for the duration of calls to such functions may be required.
>   .TP
>   .I cwd
> @@ -796,7 +796,7 @@ Functions marked with
>   as an MT-Safety issue may temporarily
>   change the current working directory during their execution,
>   which may cause relative pathnames to be resolved in unexpected ways in
> -other threads or within asynchronous signal or cancellation handlers.
> +other threads or within asynchronous signal or cancelation handlers.
>   .IP
>   This is not enough of a reason to mark so-marked functions as MT-Unsafe,
>   .\" or AS-Unsafe,
> diff --git a/man7/nptl.7 b/man7/nptl.7
> index 0133c0a..ea17940 100644
> --- a/man7/nptl.7
> +++ b/man7/nptl.7
> @@ -34,7 +34,7 @@ Linux systems.
>   .SS NPTL and signals
>   NPTL makes internal use of the first two real-time signals
>   (signal numbers 32 and 33).
> -One of these signals is used to support thread cancellation and POSIX timers
> +One of these signals is used to support thread cancelation and POSIX timers
>   (see
>   .BR timer_create (2));
>   the other is used as part of a mechanism that ensures all threads in
> diff --git a/man7/pthreads.7 b/man7/pthreads.7
> index 6f4f6e7..380aeb2 100644
> --- a/man7/pthreads.7
> +++ b/man7/pthreads.7
> @@ -257,17 +257,17 @@ pthread_setcanceltype()
>   .in
>   .SS Cancellation points
>   POSIX.1 specifies that certain functions must,
> -and certain other functions may, be cancellation points.
> +and certain other functions may, be cancelation points.
>   If a thread is cancelable, its cancelability type is deferred,
> -and a cancellation request is pending for the thread,
> +and a cancelation request is pending for the thread,
>   then the thread is canceled when it calls a function
> -that is a cancellation point.
> +that is a cancelation point.
>   .PP
> -The following functions are required to be cancellation points by
> +The following functions are required to be cancelation points by
>   POSIX.1-2001 and/or POSIX.1-2008:
>   .PP
>   .\" FIXME
> -.\" Document the list of all functions that are cancellation points in glibc
> +.\" Document the list of all functions that are cancelation points in glibc
>   .in +4n
>   .EX
>   accept()
> @@ -331,7 +331,7 @@ writev()
>   .EE
>   .in
>   .PP
> -The following functions may be cancellation points according to
> +The following functions may be cancelation points according to
>   POSIX.1-2001 and/or POSIX.1-2008:
>   .PP
>   .in +4n
> @@ -567,23 +567,23 @@ wscanf()
>   .in
>   .PP
>   An implementation may also mark other functions
> -not specified in the standard as cancellation points.
> +not specified in the standard as cancelation points.
>   In particular, an implementation is likely to mark
> -any nonstandard function that may block as a cancellation point.
> +any nonstandard function that may block as a cancelation point.
>   (This includes most functions that can touch files.)
>   .PP
>   It should be noted that even if an application is not using
> -asynchronous cancellation, that calling a function from the above list
> +asynchronous cancelation, that calling a function from the above list
>   from an asynchronous signal handler may cause the equivalent of
> -asynchronous cancellation.
> +asynchronous cancelation.
>   The underlying user code may not expect
> -asynchronous cancellation and the state of the user data may become
> +asynchronous cancelation and the state of the user data may become
>   inconsistent.
>   Therefore signals should be used with caution when
> -entering a region of deferred cancellation.
> -.\" So, scanning "cancellation point" comments in the glibc 2.8 header
> +entering a region of deferred cancelation.
> +.\" So, scanning "cancelation point" comments in the glibc 2.8 header
>   .\" files, it looks as though at least the following nonstandard
> -.\" functions are cancellation points:
> +.\" functions are cancelation points:
>   .\" endnetgrent
>   .\" endspent
>   .\" epoll_pwait
> diff --git a/man7/signal-safety.7 b/man7/signal-safety.7
> index 9e8cd3f..b0108c8 100644
> --- a/man7/signal-safety.7
> +++ b/man7/signal-safety.7
> @@ -322,9 +322,9 @@ is likely to remove
>   from the list of async-signal-safe functions.
>   .\"
>   .IP * 3
> -Asynchronous signal handlers that call functions which are cancellation
> -points and nest over regions of deferred cancellation may trigger
> -cancellation whose behavior is as if asynchronous cancellation had
> +Asynchronous signal handlers that call functions which are cancelation
> +points and nest over regions of deferred cancelation may trigger
> +cancelation whose behavior is as if asynchronous cancelation had
>   occurred and may cause application state to become inconsistent.
>   .\"
>   .SS errno
> 

-- 
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-11-29 13:17 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-13 11:56 [patch] pthread_cancel.3, pthread_cleanup_push_defer_np.3, pthread_setcancelstate.3, pthread_testcancel.3, pthreads.7: tfix Samanta Navarro
2021-11-13 12:40 ` G. Branden Robinson
2021-11-13 13:00   ` Samanta Navarro
2021-11-22 17:09     ` Alejandro Colomar (man-pages)
2021-11-24 11:58       ` Samanta Navarro
2021-11-29 11:59         ` Alejandro Colomar (man-pages)

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.