PTHREAD_CANCEL(3P)

🌸 PROLOG 🌸

ok so bestie, heads up: this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (so like, go read the corresponding Linux manual page for the deets on Linux behavior), or honestly the interface may not even be implemented on Linux at all. 💀

---

✨ NAME ✨

pthread_cancel — cancel execution of a thread

---

🎀 SYNOPSIS 🎀

#include <pthread.h>

int pthread_cancel(pthread_t thread);

---

💖 DESCRIPTION 💖

Okay so pthread_cancel() shall request that thread be canceled. That's the whole vibe. But here's the tea: the target thread's cancelability state and type determines when the cancellation actually takes effect. It's giving "I sent the request, but they'll get to it when they get to it." 🦋

When the cancellation is acted on, the cancellation cleanup handlers for thread shall be called. When the last cancellation cleanup handler returns, the thread-specific data destructor functions shall be called for thread. And when the last destructor function returns, thread shall be terminated. That's the whole pipeline, in order, no skipping steps. 💅

Also super important: the cancellation processing in the target thread shall run asynchronously with respect to the calling thread returning from pthread_cancel(). So like, the caller just walks away and the target does its thing on its own time. main character energy for real.

---

⭐ RETURN VALUE ⭐

If successful, pthread_cancel() shall return zero; otherwise, an error number shall be returned to indicate the error. Simple as. 😌

---

🔥 ERRORS 🔥

The pthread_cancel() function shall not return an error code of [EINTR]. That one's off the table, no cap.

The following sections are informative.

---

🧚 EXAMPLES 🧚

None. (yeah, we're all a little disappointed, moving on 🙈)

---

🌈 APPLICATION USAGE 🌈

None. (same energy, bestie)

---

👑 RATIONALE 👑

Okay so this part is actually kind of iconic — let's talk about the design drama. Two alternative functions were considered for sending the cancellation notification to a thread:

1. Define a new SIGCANCEL signal that had the cancellation semantics when delivered.
2. Define the new pthread_cancel() function, which would trigger the cancellation semantics.

The advantage of a new signal was that so much of the delivery criteria were identical to that used when trying to deliver a signal that making cancellation notification a signal was seen as consistent. And indeed, many implementations implement cancellation using a special signal. ✨

On the other hand — and this is the plot twist — there would be no signal functions that could be used with this signal except pthread_kill(), and the behavior of the delivered cancellation signal would be unlike any previously existing defined signal. It's giving "new kid who refuses to follow the dress code." 😭

The benefits of a special function include the recognition that this signal would be defined because of the similar delivery criteria, and that this is the only common behavior between a cancellation request and a signal. In addition, the cancellation delivery mechanism does not have to be implemented as a signal. There are also strong, if not stronger, parallels with language exception mechanisms than with signals — parallels that are potentially obscured if the delivery mechanism is visibly closer to signals. 🫶

In the end, it was considered that as there were so many exceptions to the use of the new signal with existing signals functions, it would be misleading. A special function has resolved this problem. This function was carefully defined so that an implementation wishing to provide the cancellation functions on top of signals could do so. The special function also means that implementations are not obliged to implement cancellation with signals. Freedom, periodt. 💅

And one more thing bestie, a lil recommendation tucked in here: if an implementation detects use of a thread ID after the end of its lifetime, it is recommended that the function should fail and report an [ESRCH] error. So don't be out here using dead thread IDs, that's so not the vibe. 💀

---

🦋 FUTURE DIRECTIONS 🦋

None.

---

💜 SEE ALSO 💜

• pthread_exit()
• pthread_cond_timedwait()
• pthread_join()
• pthread_setcancelstate()

The Base Definitions volume of POSIX.1‐2017, <pthread.h> ⭐

---

📜 COPYRIGHT 📜

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .

---

and that's the whole page, bestie!! 🎀✨ this one's from IEEE/The Open Group, 2017, and it's the PTHREAD_CANCEL(3P) page — thanks for reading, love u, go cancel some threads responsibly 💖