pthread_exit(3)

💖 pthread_exit(3) — bestie edition 💖

okay so you wanna know about pthread_exit? Welcome to the pthread_exit(3) page, babes — it's a library function, part of the POSIX threads library situation, and it's lowkey one of the most iconic ways to dip out of a thread. Let's get into it 🫶

---

✨ NAME ✨

pthread_exit — terminate the calling thread 💅

📚 LIBRARY 📚

POSIX threads library — that's libpthread, and you link it with -lpthread.

🌸 SYNOPSIS 🌸

#include <pthread.h>

[[noreturn]] void pthread_exit(void *retval);

🦋 DESCRIPTION 🦋

okay so here's the tea. pthread_exit() terminates the calling thread, and it hands a value back through retval — and if that thread is joinable, that value is available to another thread in the same process that goes and calls pthread_join(3). it's giving "leaving a little note behind for whoever comes looking" ✨

Any clean-up handlers you set up with pthread_cleanup_push(3) that haven't been popped yet? They get popped and executed, and they go in the reverse of the order in which they were pushed. LIFO forever, no cap. 🎀

And if the thread has any thread-specific data? Then, after all those clean-up handlers have run, the corresponding destructor functions get called, in an unspecified order. (unspecified order = don't @ me about which one goes first, okay 😭)

When a thread terminates, listen — process-shared resources are not released. Like, at all. That means stuff like mutexes, condition variables, semaphores, and file descriptors are just... still there. And functions you registered using atexit(3) are not called. Yeah. Not called. 💀

BUT — and this is the plot twist — after the last thread in a process terminates, the process itself terminates, as by calling exit(3) with an exit status of zero. So at that point process-shared resources are released and functions registered using atexit(3) are called. The finale hits different 👑

🎯 RETURN VALUE 🎯

This function does not return to the caller. It just... doesn't come back. It's on its own journey now 🧚

💀 ERRORS 💀

This function always succeeds. Like, always. Iconic behavior honestly.

👑 ATTRIBUTES 👑

For an explanation of the terms used in this section, go check out attributes(7).

• Interface: pthread_exit()
  • Attribute: Thread safety
  • Value: MT-Safe ✅

📜 STANDARDS 📜

POSIX.1-2008. periodt.

🕰️ HISTORY 🕰️

POSIX.1-2001. yes bestie, the lore goes back that far 🌈

📝 NOTES 📝

• If you do a return from the start function of any thread that isn't the main thread, that results in an implicit call to pthread_exit(), and it uses the function's return value as the thread's exit status.
• If you want the other threads to keep on doing their thing, the main thread should terminate by calling pthread_exit() rather than exit(3). Big difference. Choose wisely 💅
• The value pointed to by retval should not live on the calling thread's stack, because the contents of that stack are undefined after the thread terminates. So like, don't point at something that's about to evaporate, bestie 🙈

🐛 BUGS 🐛

Currently, there are limitations in the kernel implementation logic for wait(2)ing on a stopped thread group with a dead thread group leader. This can manifest in problems such as a locked terminal if a stop signal is sent to a foreground process whose thread group leader has already called pthread_exit(). Yeah, that's a real one. Not cute, but real. 😭

🔗 SEE ALSO 🔗

pthread_create(3), pthread_join(3), pthreads(7)

---

and that's the whole page, bestie 🫶 this was Linux man-pages 6.20, dated 2025-05-17, signing off from pthread_exit(3) — go forth and exit your threads responsibly 💖✨🎀