PTHREAD_A...TGUARDSIZE(3P)

πŸ’… PTHREAD_A...TGUARDSIZE(3P) β€” bestie edition ✨

okay so this is a page from the POSIX Programmer's Manual (yes, the whole thing, it's a series) and it's all about guard pages on thread stacks. before we go any further, the mandatory vibe check:

This manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (consult the corresponding Linux manual page for details of Linux behavior), or the interface may not be implemented on Linux.

like, the Linux girlies might do it differently, or might not show up to the party at all. check your local manpage, no cap. πŸ™ˆ


🌸 NAME 🌸

pthread_attr_getguardsize, pthread_attr_setguardsize β€” get and set the thread guardsize attribute

it does exactly what it says on the tin. get it, set it, guardsize, periodt. πŸ’…


πŸŽ€ SYNOPSIS πŸŽ€

#include <pthread.h>

int pthread_attr_getguardsize(const pthread_attr_t *restrict attr,
    size_t *restrict guardsize);
int pthread_attr_setguardsize(pthread_attr_t *attr,
    size_t guardsize);

two functions, one friendship. one reads, one writes. iconic duo honestly. 🫢


✨ DESCRIPTION ✨

so, pthread_attr_getguardsize() shall get the guardsize attribute inside the attr object. and where does that value go? it gets returned in the guardsize parameter. yes bestie, out-parameter style. classic. πŸ’–

then pthread_attr_setguardsize() shall set the guardsize attribute in the attr object. the new value comes from the guardsize parameter. and here's the tea:

  • if guardsize is zero, a guard area shall not be provided for threads created with attr.
  • if guardsize is greater than zero, a guard area of at least guardsize bytes shall be provided for each thread created with attr.

okay but like, what even is a guard area? let me explain, bestie. the guardsize attribute controls the size of the guard area for the created thread's stack. it's literally protection against overflow of the stack pointer. if a thread's stack is created with guard protection, the implementation allocates extra memory at the overflow end of the stack as a buffer against stack overflow of the stack pointer. and if your application overflows into this buffer β€” an error shall result (possibly in a SIGSEGV signal being delivered to the thread). πŸ’€ so like, it's a bouncer at the club. don't test it.

the rounding situation: a conforming implementation may round up the value contained in guardsize to a multiple of the configurable system variable {PAGESIZE} (see <sys/mman.h>). and if an implementation rounds up the value of guardsize to a multiple of {PAGESIZE}, then a call to pthread_attr_getguardsize() specifying attr shall store in the guardsize parameter the guard size specified by the previous pthread_attr_setguardsize() function call. so you get back what you put in, not the rounded version. noted. πŸ“

the default value of the guardsize attribute is implementation-defined. iykyk.

plot twist time: if the stackaddr attribute has been set (that is, the caller is allocating and managing its own thread stacks), the guardsize attribute shall be ignored and no protection shall be provided by the implementation. it is the responsibility of the application to manage stack overflow along with stack allocation and management in this case. so if you're doing your own stacks, the guard is off duty. you're on your own, bestie. 😭

the behavior is undefined if the value specified by the attr argument to pthread_attr_getguardsize() or pthread_attr_setguardsize() does not refer to an initialized thread attributes object. undefined behavior!! do not do this!! uninitialized attr is not the vibe. 🚫

πŸ”₯ RETURN VALUE πŸ”₯

if successful, the pthread_attr_getguardsize() and pthread_attr_setguardsize() functions shall return zero. otherwise, an error number shall be returned to indicate the error. zero is the slay, anything else is the flop. ✨


πŸ’œ ERRORS πŸ’œ

these functions shall fail if:

  • EINVAL β€” the parameter guardsize is invalid.

and one more thing: these functions shall not return an error code of [EINTR]. so don't go looking for it, it's not coming. 🫢

The following sections are informative.

so like, everything from here down is bonus content. still valid, still cute, just not the normative requirements. πŸ’–


πŸ¦‹ EXAMPLES πŸ¦‹

🌈 Retrieving the guardsize Attribute

this example shows how to obtain the guardsize attribute of a thread attribute object. look at her go:

#include <pthread.h>

pthread_attr_t thread_attr;
size_t  guardsize;
int     rc;

/* code initializing thread_attr */
...

rc = pthread_attr_getguardsize (&thread_attr, &guardsize);
if (rc != 0)  {
    /* handle error */
    ...
}
else {
    if (guardsize > 0) {
    /* a guard area of at least guardsize bytes is provided */
    ...
    }
    else {
    /* no guard area provided */
    ...
    }
}

check the return code, then check the value. guard area or no guard area, that's the whole question. so simple, so clean, ate. πŸ‘‘


πŸ“ APPLICATION USAGE πŸ“

None.

literally nothing. the void. the silence. moving on. πŸ’€


⭐ RATIONALE ⭐

why does the guardsize attribute even exist, you ask? two reasons, bestie:

  1. Overflow protection can potentially result in wasted system resources. an application that creates a large number of threads, and which knows its threads never overflow their stack, can save system resources by turning off guard areas.
  2. When threads allocate large data structures on the stack, large guard areas may be needed to detect stack overflow.

see? one size does not fit all. sometimes you want the bouncer, sometimes you're broke and can't afford the bouncer. πŸ’Έ

and the default size of the guard area is left implementation-defined since on systems supporting very large page sizes, the overhead might be substantial if at least one guard page is required by default. makes sense tbh. big pages, big bills. 😭

one more thing: if an implementation detects that the value specified by the attr argument to pthread_attr_getguardsize() or pthread_attr_setguardsize() does not refer to an initialized thread attributes object, it is recommended that the function should fail and report an [EINVAL] error. recommended, not required. so like, bestie behavior would be to fail, but it's a suggestion. 🫢


🧚 FUTURE DIRECTIONS 🧚

None.

again with the nothing. the page said "rest" and meant it. ✨


πŸ’– SEE ALSO πŸ’–

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

go read those if you want the full lore. the source material. the origin story. πŸ“š


okay so legally speaking, bestie:

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 was brought to you by IEEE/The Open Group, 2017 β€” yeah the copyright date is old but the knowledge is timeless, periodt. now go guard your stacks. πŸ’…πŸ’–

πŸ“¦ where this page comes from