e49ae776cc
Zephyr must support all functionality of the XSI_THREADS_EXT subprofiling option group in order to claim it supports that subprofiling option group. The XSI_THREADS_EXT option group is critical to be able to run POSIX threads with statically allocated thread stacks, which has been a feature of the implementation since it was initially added. The pthread_getconcurrency() and pthread_setconcurrency() functions are the only remaining, unimplemented functions of the XSI_THREADS_EXT option group. Implement pthread_getconcurrency() and pthread_setconcurrency() via the more "posixly correct" interpretation of the specification. I.e. as the pthread_t:k_thread relationship is 1:1 and not M:N, Zephyr does not support multiplexing of user threads on top of schedulable kernel entities (i.e. "user threads" are directly mapped to native threads, just like linuxthreads or NPTL are in Linux). For that reason, to be "posixly correct", we should save the provided value via pthread_setconcurrency(), in the absense of errors, and also return that same value back via pthread_getconcurrency(), even though that serves zero purpose in Zephyr for the foreseeable future. Note: the specification also states "an implementation can always ignore any calls to pthread_setconcurrency() and return a constant for pthread_getconcurrency()." For that reason, the implementation may be revisited at a later time when when considering optimizations and when there is a better system in place for documenting deviations. Any such optimization should be explicitly controlled via Kconfig. Signed-off-by: Christopher Friedt <cfriedt@meta.com> |
||
---|---|---|
.. | ||
acpi | ||
cpp | ||
crc | ||
hash | ||
libc | ||
open-amp | ||
os | ||
posix | ||
runtime | ||
smf | ||
CMakeLists.txt | ||
Kconfig |