Fix finding pthread_*name_np on vanilla musl libc #2939
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2939 +/- ##
=======================================
Coverage 99.64% 99.64%
=======================================
Files 116 116
Lines 17503 17506 +3
Branches 3148 3148
=======================================
+ Hits 17441 17444 +3
Misses 43 43
Partials 19 19
|
|
I ran into this for #2933 and ended up just making that require |
Fix the `pthread_getname_np` and `pthread_setname_np` search logic
to support vanilla versions of musl and CPython, e.g. as used on Gentoo
musl systems. On such systems, there is no "libpthread.so" (there is
only a static library) and the relevant functions are found
in "libc.so". Additionally, `ctypes.util.find_library("c")` does not
work because of an old unsolved bug in CPython (linked in the code).
To resolve the problem, add a fallback to trying `libc.so` if no pthread
library can be found. This roughly covers three possibilities:
- a "typical" system with `libpthread.so` will find that library
and use it
- a musl system will fall back to `libc.so`, load that library and find
pthread functions there
- any other system will try to load `libc.so`, and fail
The code in `get_os_thread_name_func()` remains fully relaxed, allowing
either CDLL construction (i.e. finding the library) to fail,
or the library not to contain `pthread_setname_np`.
The code in `test_threads.py` was made more relaxed — rather than
skipping if `libpthread.so` does not exist, it tries to load `libc.so`
as a fallback, and skips if that fails.
Originally reported as https://bugs.gentoo.org/923257.
|
Fixed and added a newsfragment. |
|
Hey @mgorny, it looks like that was the first time we merged one of your PRs! Thanks so much! 🎉 🎂 If you want to keep contributing, we'd love to have you. So, I just sent you an invitation to join the python-trio organization on Github! If you accept, then here's what will happen:
If you want to read more, here's the relevant section in our contributing guide. Alternatively, you're free to decline or ignore the invitation. You'll still be able to contribute as much or as little as you like, and I won't hassle you about joining again. But if you ever change your mind, just let us know and we'll send another invitation. We'd love to have you, but more importantly we want you to do whatever's best for you. If you have any questions, well... I am just a humble Python script, so I probably can't help. But please do post a comment here, or in our chat, or on our forum, whatever's easiest, and someone will help you out! |
|
Thanks! |
|
Thank you for the contribution! |
Fix the
pthread_getname_npandpthread_setname_npsearch logic to support vanilla versions of musl and CPython, e.g. as used on Gentoo musl systems. On such systems, there is no "libpthread.so" (there is only a static library) and the relevant functions are found in "libc.so". Additionally,ctypes.util.find_library("c")does not work because of an old unsolved bug in CPython (linked in the code).To resolve the problem, add a fallback to trying
libc.soif no pthread library can be found. This roughly covers three possibilities:a "typical" system with
libpthread.sowill find that library and use ita musl system will fall back to
libc.so, load that library and find pthread functions thereany other system will try to load
libc.so, and failThe code in
get_os_thread_name_func()remains fully relaxed, allowing either CDLL construction (i.e. finding the library) to fail, or the library not to containpthread_setname_np.The code in
test_threads.pywas made more relaxed — rather than skipping iflibpthread.sodoes not exist, it tries to loadlibc.soas a fallback, and skips if that fails.Originally reported as https://bugs.gentoo.org/923257.