PTHREAD...SPECIFIC(3POSIX)

πŸ’… PTHREAD...SPECIFIC β€” thread-specific data management ✨

okay bestie, listen. this is the POSIX Programmer's Manual page for pthread_getspecific and pthread_setspecific, and it's giving per-thread storage realness. 🧚

Quick heads up before we lock in: the Linux implementation of this interface may differ from the POSIX spec (so go check the corresponding Linux manual page for the deets on Linux behavior), and the interface might not even be implemented on Linux at all. πŸ™ˆ

πŸŽ€ NAME πŸŽ€

pthread_getspecific, pthread_setspecific β€” thread-specific data management


🌸 SYNOPSIS 🌸

#include <pthread.h>

void *pthread_getspecific(pthread_key_t key);
int pthread_setspecific(pthread_key_t key, const void *value);

✨ DESCRIPTION ✨

so pthread_getspecific() shall return the value that's currently bound to the specified key on behalf of the calling thread. that's it, that's the vibe. 🫢

and pthread_setspecific() shall associate a thread-specific value with a key that you got from a previous call to pthread_key_create(). the way that different threads can bind different values to the same key?? iconic. these values are typically pointers to blocks of dynamically allocated memory that have been reserved for use by the calling thread. no cap. πŸ”₯

πŸ’€ danger zone alert: the effect of calling pthread_getspecific() or pthread_setspecific() with a key value that was not obtained from pthread_key_create(), or after that key has been deleted with pthread_key_delete(), is undefined. we do not do that. periodt.

both pthread_getspecific() and pthread_setspecific() may be called from a thread-specific data destructor function. a call to pthread_getspecific() for the thread-specific data key being destroyed shall return the value NULL, unless the value is changed (after the destructor starts) by a call to pthread_setspecific(). 🌈

calling pthread_setspecific() from a thread-specific data destructor routine may result either in lost storage (after at least PTHREAD_DESTRUCTOR_ITERATIONS attempts at destruction) or in an infinite loop. 😭 so like. be careful.

both functions may be implemented as macros. yes fr fr. πŸ‘‘


πŸ’– RETURN VALUE πŸ’–

pthread_getspecific() shall return the thread-specific data value associated with the given key. and if no thread-specific data value is associated with key, then the value NULL shall be returned. simple as that. ✨

pthread_setspecific(), if successful, shall return zero. otherwise, an error number shall be returned to indicate the error. slay. πŸ’…


πŸ¦‹ ERRORS πŸ¦‹

no errors are returned from pthread_getspecific(). none. zero. it's just built different. 😌

the pthread_setspecific() function shall fail if:

  • ENOMEM β€” insufficient memory exists to associate the non-NULL value with the key. 😭

and also, pthread_setspecific() shall not return an error code of [EINTR]. noted bestie.

🌟 psst: the following sections are informative. (they're the bonus content, not the rules.)

πŸ“ EXAMPLES πŸ“

None. (yeah, literally none, we're moving on πŸ™ˆ)


🌺 APPLICATION USAGE 🌺

None. (also none, the plot is not thickening 😭)


πŸ‘‘ RATIONALE πŸ‘‘

performance and ease-of-use of pthread_getspecific() are critical for functions that rely on maintaining state in thread-specific data. because no errors are required to be detected by it, and because the only error that could be detected is the use of an invalid key, the function to pthread_getspecific() has been designed to favor speed and simplicity over error reporting. it's giving "we're fast, we're chill, we don't do error handling". ⭐

and if an implementation detects that the value specified by the key argument to pthread_setspecific() does not refer to a key value obtained from pthread_key_create(), or refers to a key that has been deleted with pthread_key_delete(), it is recommended that the function should fail and report an [EINVAL] error. that's the recommendation, bestie. 🫢


🌈 FUTURE DIRECTIONS 🌈

None. (the future is... nothing. immaculate. πŸ’œ)


πŸŽ€ SEE ALSO πŸŽ€

  • pthread_key_create()

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


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 .


okay that's the whole page, bestie πŸ₯° this came from IEEE/The Open Group, dated 2017, and it lives under the manual name PTHREAD...SPECIFIC(3POSIX). go forth and manage your thread-specific data, you absolute icon πŸ’…βœ¨πŸ¦‹