man3/: Say cancelation instead of cancellation

It's the most common spelling in this project.

Signed-off-by: Alejandro Colomar <alx@kernel.org>

3 files changed, 7 insertions, 7 deletions

diff --git a/man3/pthread_cond_init.3 b/man3/pthread_cond_init.3
index 820ce9abb4..8472d2eb54 100644
--- a/man3/pthread_cond_init.3
+++ b/man3/pthread_cond_init.3
@@ -110,12 +110,12 @@ except checking that the condition has no waiting threads.
 .
 .SH CANCELLATION
 \fBpthread_cond_wait\fP and \fBpthread_cond_timedwait\fP
-are cancellation points.
+are cancelation points.
 If a thread is cancelled while suspended in one of these functions,
 the thread immediately resumes execution,
 then locks again the \fImutex\fP
 argument to \fBpthread_cond_wait\fP and \fBpthread_cond_timedwait\fP,
-and finally executes the cancellation.
+and finally executes the cancelation.
 Consequently,
 cleanup handlers are assured that \fImutex\fP is locked
 when they are called.
diff --git a/man3/pthread_key_create.3 b/man3/pthread_key_create.3
index ea89501a08..ad8a397f4b 100644
--- a/man3/pthread_key_create.3
+++ b/man3/pthread_key_create.3
@@ -59,7 +59,7 @@ is \fBNULL\fP in all currently executing threads.
 The \fIdestr_function\fP argument,
 if not \fBNULL\fP,
 specifies a destructor function associated with the key.
-When a thread terminates via \fBpthread_exit\fP or by cancellation,
+When a thread terminates via \fBpthread_exit\fP or by cancelation,
 \fIdestr_function\fP is called with arguments
 the value associated with the key in that thread.
 The \fIdestr_function\fP is not called if that value is \fBNULL\fP.
diff --git a/man3/pthread_mutex_init.3 b/man3/pthread_mutex_init.3
index 2fcda6e475..d9b1c5267e 100644
--- a/man3/pthread_mutex_init.3
+++ b/man3/pthread_mutex_init.3
@@ -130,16 +130,16 @@ except checking that the mutex is unlocked.
 .
 .
 .SH CANCELLATION
-None of the mutex functions is a cancellation point,
+None of the mutex functions is a cancelation point,
 not even \fBpthread_mutex_lock\fP,
 in spite of the fact that it can suspend a thread for arbitrary durations.
 This way,
-the status of mutexes at cancellation points is predictable,
-allowing cancellation handlers
+the status of mutexes at cancelation points is predictable,
+allowing cancelation handlers
 to unlock precisely those mutexes that need to be unlocked
 before the thread stops executing.
 Consequently,
-threads using deferred cancellation
+threads using deferred cancelation
 should never hold a mutex for extended periods of time.
 .
 .