PTHREAD_EXIT(3P)

💅 PTHREAD_EXIT — thread termination (POSIX Programmer's Manual, PTHREAD_EXIT(3P))

🫶 PROLOG

Okay bestie, listen up — this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (so go consult the corresponding Linux manual page for the deets on Linux behavior), or honestly the interface may just not be implemented on Linux at all. 🙈

---

✨ NAME ✨

pthread_exit — thread termination. It's giving "exit, but make it a thread." 💀

---

🎀 SYNOPSIS 🎀

#include <pthread.h>

void pthread_exit(void *value_ptr);

---

💖 DESCRIPTION 💖

So the pthread_exit() function shall terminate the calling thread and make the value value_ptr available to any successful join with the terminating thread. That's the whole vibe: you dip out, and whatever you passed as value_ptr is waiting for whoever joins you. 👑

Any cancellation cleanup handlers that have been pushed and not yet popped shall be popped in the reverse order that they were pushed and then executed. LIFO, periodt. After all the cancellation cleanup handlers have been executed, if the thread has any thread-specific data, the appropriate destructor functions shall be called in an unspecified order — so don't come for me about the order, there literally isn't one. 🌸

🚨 Big one: thread termination does not release any application visible process resources — including, but not limited to, mutexes and file descriptors. It also doesn't do any process-level cleanup actions, including, but not limited to, calling any atexit() routines that may exist. You are closing one tab, not the whole browser. 💀

An implicit call to pthread_exit() is made when a thread other than the thread in which main() was first invoked returns from the start routine that was used to create it. The function's return value shall serve as the thread's exit status. So if you just return from your thread function, surprise — you basically called this function yourself. 🦋

⚠️ The behavior of pthread_exit() is undefined if called from a cancellation cleanup handler or destructor function that was invoked as a result of either an implicit or explicit call to pthread_exit(). Do not do this. Not even a little. 😭

After a thread has terminated, the result of access to local (auto) variables of the thread is undefined. So no, bestie — references to local variables of the exiting thread should not be used for the pthread_exit() value_ptr parameter value. Your stack is gone, it's in the wind, it's not coming back. 🍓

The process shall exit with an exit status of 0 after the last thread has been terminated. The behavior shall be as if the implementation called exit() with a zero argument at thread termination time. Last one out turns off the lights. 🌙

---

🔥 RETURN VALUE 🔥

The pthread_exit() function cannot return to its caller. Like, at all. It's not ghosting you, it literally cannot come back. 💅

---

😭 ERRORS 😭

No errors are defined. (Iconic. Zero drama. No notes. ✨)

The following sections are informative.

---

🌈 EXAMPLES 🌈

None. (Nothing to show, everything to know. 💜)

---

🧚 APPLICATION USAGE 🧚

None. (Same energy. Moving on. 🎀)

---

👑 RATIONALE 👑

The normal mechanism by which a thread terminates is to return from the routine that was specified in the pthread_create() call that started it. The pthread_exit() function provides the capability for a thread to terminate without requiring a return from the start routine of that thread — which makes it a function analogous to exit(). So yeah, it's exit() but for your one little thread. Main character energy, honestly. 🦋

Regardless of the method of thread termination, any cancellation cleanup handlers that have been pushed and not yet popped are executed, and the destructors for any existing thread-specific data are executed. This volume of POSIX.1‐2017 requires that cancellation cleanup handlers be popped and called in order. After all cancellation cleanup handlers have been executed, thread-specific data destructors are called, in an unspecified order, for each item of thread-specific data that exists in the thread. Why this ordering? Because cancellation cleanup handlers may rely on thread-specific data — so you gotta do the handlers first, then the destructors. It's a whole sequence, iykyk. 💅

As the meaning of the status is determined by the application (except when the thread has been canceled, in which case it is PTHREAD_CANCELED), the implementation has no idea what an illegal status value is — which is exactly why no address error checking is done. The library can't judge what you meant, so it doesn't try. 🤷♀️

---

⭐ FUTURE DIRECTIONS ⭐

None. (The future is bright and also empty. ✨)

---

💜 SEE ALSO 💜

• exit()
• pthread_create()
• pthread_join()
• 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 came to you courtesy of IEEE/The Open Group, dated 2017, and it lives at PTHREAD_EXIT(3P) in the POSIX Programmer's Manual. Go forth and terminate your threads responsibly — and remember, no releasing mutexes on your way out. 😭💖