Fix finding pthread_*name_np on vanilla musl libc

[mgorny]

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.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (05c5df2) 99.64% compared to head (c8c1957) 99.64%.

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           

Files	Coverage Δ
src/trio/_core/_thread_cache.py	100.00% <100.00%> (ø)
src/trio/_tests/test_threads.py	100.00% <100.00%> (ø)

[A5rocks]

I ran into this for #2933 and ended up just making that require musl-dev instead of figuring this out. Thanks for putting in the work!

[mgorny]

Fixed and added a newsfragment.

[CoolCat467]

Seeing this and your description, this makes sense and I think it looks good!

[trio-bot]

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:

• Github will automatically subscribe you to notifications on all our repositories. (But you can unsubscribe again if you don't want the spam.)

• You'll be able to help us manage issues (add labels, close them, etc.)

• You'll be able to review and merge other people's pull requests

• You'll get a [member] badge next to your name when participating in the Trio repos, and you'll have the option of adding your name to our member's page and putting our icon on your Github profile (details)

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!

[mgorny]

Thanks!

[jakkdl]

Thank you for the contribution!
Can also see that it works in CI over in #2933
https://github.com/python-trio/trio/actions/runs/7712303460/job/21019556518?pr=2933