pthread_at...heritsched(3)

πŸ’– pthread_at...heritsched(3) πŸ’–

hiii bestie, this is the page from the Library Functions Manual (yep that's the manual it lives in) and it's all about telling a thread whether it gets to be its own scheduling main character or just copies the vibe of whoever created it. no cap, it's shorter than it looks. let's go πŸ¦‹


🌸 NAME 🌸

pthread_attr_setinheritsched, pthread_attr_getinheritsched β€” set/get inherit-scheduler attribute in thread attributes object

πŸ“š LIBRARY πŸ“š

POSIX threads library (libpthread, -lpthread)

✨ SYNOPSIS ✨

#include <pthread.h>

int pthread_attr_setinheritsched(pthread_attr_t *attr,
                                 int inheritsched);
int pthread_attr_getinheritsched(const pthread_attr_t *restrict attr,
                                 int *restrict inheritsched);

πŸ’… DESCRIPTION πŸ’…

okay so pthread_attr_setinheritsched() sets the inherit-scheduler attribute of the thread attributes object that attr points at, and it sets it to whatever you passed in inheritsched. and what does that attribute even do? it's the little switch that decides whether a thread created with that attributes object attr inherits its scheduling attributes from the thread that's calling, or whether it takes them from attr instead. it's giving "who am I really, deep down" but for thread attributes πŸ™ˆ

the scheduling attributes that get swayed by the inherit-scheduler attribute are these three:

and here are the values you're allowed to put in inheritsched:

  • PTHREAD_INHERIT_SCHED β€” threads created using attr straight up inherit their scheduling attributes from the creating thread, and the scheduling attributes sitting in attr get ignored. ghosted. bye πŸ’€
  • PTHREAD_EXPLICIT_SCHED β€” threads created using attr take their scheduling attributes from the values specified by the attributes object itself. independent queen πŸ‘‘

the default setting of the inherit-scheduler attribute in a brand new (newly initialized) thread attributes object is PTHREAD_INHERIT_SCHED.

and pthread_attr_getinheritsched() does the reading side: it returns the inherit-scheduler attribute of the thread attributes object attr into the buffer that inheritsched points to. 🫢

πŸŽ€ RETURN VALUE πŸŽ€

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

😭 ERRORS 😭

pthread_attr_setinheritsched() can fail with this one:

  • EINVAL β€” invalid value in inheritsched.

and heads up bestie, POSIX.1 also documents an optional ENOTSUP error for pthread_attr_setinheritsched(), described as "attempt was made to set the attribute to an unsupported value". optional means it might not even show up, so don't build your whole personality around it ✨

πŸ’œ ATTRIBUTES πŸ’œ

for an explanation of the terms used in this section, go peek at attributes(7).

  • Interface: pthread_attr_setinheritsched(), pthread_attr_getinheritsched()
  • Attribute: Thread safety
  • Value: MT-Safe

thread-safe icon behavior, we love to see it πŸ”₯

🌈 STANDARDS 🌈

POSIX.1-2008. periodt.

πŸ‘‘ HISTORY πŸ‘‘

glibc 2.0. and POSIX.1-2001. ancient but still slaying πŸ’…

πŸ’€ BUGS πŸ’€

okay this part is messy, stay with me.

as at glibc 2.8, if a thread attributes object is initialized using pthread_attr_init(3), then the scheduling policy of the attributes object is set to SCHED_OTHER and the scheduling priority is set to 0. cute, fine, normal.

but if the inherit-scheduler attribute is then set to PTHREAD_EXPLICIT_SCHED, then a thread created using that attribute object wrongly inherits its scheduling attributes from the creating thread. yeah. it just does the wrong thing 😭 not the vibe you asked for, not the vibe you get.

this bug does not happen if either the scheduling policy attribute or the scheduling priority attribute is explicitly set in the thread attributes object before calling pthread_create(3). so like, set one of those and you're fine. iykyk.

🧚 EXAMPLES 🧚

see pthread_setschedparam(3).

πŸ“ SEE ALSO πŸ“


okay that's the whole page bestie, go forth and schedule responsibly 🌟

this little love letter came to you from Linux man-pages 6.20, dated 2025-05-17 πŸ’– mwah, bye! πŸŽ€πŸ¦‹βœ¨

πŸ“¦ where this page comes from
  • arch rolling: man-pages 6.20-1 Β· BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
  • nixpkgs unstable: man-pages 6.20
  • πŸ“œ the page's license: Linux-man-pages-copyleft
  • πŸ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms