pthread_setcancelstate(3)

💖 NAME 💖

pthread_setcancelstate, pthread_setcanceltype — bestie, it's time to set your cancelability state and type ✨

---

📚 LIBRARY 📚

POSIX threads library — that's libpthread, link it with -lpthread 🧵

---

🌸 SYNOPSIS 🌸

#include <pthread.h>

int pthread_setcancelstate(int state, int *oldstate);
int pthread_setcanceltype(int type, int *oldtype);

---

✨ DESCRIPTION ✨

Okay so pthread_setcancelstate() sets the cancelability state of the calling thread to whatever value you drop in state. The previous cancelability state of the thread gets handed back to you in the buffer that oldstate points at. And the state argument has to be one of these two, no in-betweens:

• PTHREAD_CANCEL_ENABLE — the thread is cancelable 💅 This is the default cancelability state in all new threads, including the initial thread. The thread's cancelability type is what decides when a cancelable thread will actually respond to a cancelation request.
• PTHREAD_CANCEL_DISABLE — the thread is not cancelable 🙈 If a cancelation request shows up, it's blocked until cancelability gets enabled again.

Meanwhile pthread_setcanceltype() sets the cancelability type of the calling thread to the value in type. The previous cancelability type of the thread comes back in the buffer pointed to by oldtype. And type must be one of these:

• PTHREAD_CANCEL_DEFERRED — a cancelation request is deferred until the thread next calls a function that's a cancelation point (peep pthreads(7) for that list 👀). This is the default cancelability type in all new threads, including the initial thread.

Heads up bestie: even with deferred cancelation, a cancelation point inside an asynchronous signal handler may still be acted upon, and the effect is as if it was an asynchronous cancelation. Not a drill 💀

• PTHREAD_CANCEL_ASYNCHRONOUS — the thread can be canceled at any time 😭 Typically it gets canceled immediately upon receiving a cancelation request, but ngl the system doesn't actually guarantee that.

And the set-and-get operation each of these functions does? It's atomic with respect to other threads in the process calling the same function. Periodt.

---

🫶 RETURN VALUE 🫶

On success, these functions return 0. On error, they return a nonzero error number. That's it, that's the whole vibe.

---

💀 ERRORS 💀

pthread_setcancelstate() can fail with this one:

• EINVAL — invalid value for state. Girl, that's not a real state 🙅

pthread_setcanceltype() can fail with this one:

• EINVAL — invalid value for type. Same energy.

---

🎀 ATTRIBUTES 🎀

For an explanation of the terms used in this section, go look at attributes(7). Here's the tea:

• pthread_setcancelstate(), pthread_setcanceltype() — Thread safety: MT-Safe ✅
• pthread_setcancelstate(), pthread_setcanceltype() — Async-cancel safety: AC-Safe ✅

---

👑 STANDARDS 👑

POSIX.1-2008. Certified iconic.

---

🦋 HISTORY 🦋

glibc 2.0 and POSIX.1-2001. Ancient lore fr fr.

---

🌈 NOTES 🌈

For the full details on what happens when a thread is actually canceled, go read pthread_cancel(3). It's the main character of this whole storyline.

Briefly disabling cancelability is genuinely useful when a thread is doing some critical action that absolutely must not be interrupted by a cancelation request. But — and listen closely bestie — beware of disabling cancelability for long periods, or around operations that may block for long periods, because that renders the thread unresponsive to cancelation requests. Not cute. Don't do it. 🙈

⚡ Asynchronous cancelability ⚡

Setting the cancelability type to PTHREAD_CANCEL_ASYNCHRONOUS is rarely useful. Like, genuinely. Because the thread could be canceled at any time, it cannot safely reserve resources (e.g., allocating memory with malloc(3)), acquire mutexes, semaphores, or locks, and so on. Reserving resources is unsafe because the application has no way of knowing what the state of those resources is when the thread is canceled. Like… did cancelation occur before the resources were reserved, while they were reserved, or after they were released?? Nobody knows 😭

Furthermore, some internal data structures (e.g., the linked list of free blocks managed by the malloc(3) family of functions) may be left in an inconsistent state if cancelation occurs in the middle of the function call. Consequently, clean-up handlers cease to be useful. That's the tragedy of it all 💔

Functions that can be safely asynchronously canceled are called async-cancel-safe functions. POSIX.1-2001 and POSIX.1-2008 require only that pthread_cancel(3), pthread_setcancelstate(), and pthread_setcanceltype() be async-cancel-safe. In general, other library functions can't be safely called from an asynchronously cancelable thread. Sry 🫶

Okay but here's one of the few circumstances where asynchronous cancelability is actually useful: canceling a thread that's sitting in a pure compute-bound loop. Slay, I guess. 🔥

🌍 Portability notes 🌍

The Linux threading implementations permit the oldstate argument of pthread_setcancelstate() to be NULL, in which case the info about the previous cancelability state just… doesn't get returned to the caller. Many other implementations also permit a NULL oldstat argument, but POSIX.1 does not specify this point, so portable applications should always specify a non-NULL value in oldstate. A precisely analogous set of statements applies for the oldtype argument of pthread_setcanceltype(). Keep it portable bestie, your future self will thank you 💅

---

🌟 EXAMPLES 🌟

See pthread_cancel(3). Yeah, it's a whole thing over there.

---

🔗 SEE ALSO 🔗

• pthread_cancel(3)
• pthread_cleanup_push(3)
• pthread_testcancel(3)
• pthreads(7)

---

And that's the whole page, bestie 💜 This little love letter to threads comes to you from Linux man-pages 6.20, dated 2025-05-17 — pthread_setcancelstate(3). Now go forth and cancel responsibly ✨🎀🦋