> Do you mean that signal.pthread_kill() should be removed? This function is very useful and solve some issues that cannot be solved differently. At the same time, I don't think that it's possible to workaround the crashes. At least, I don't see how: pthread_kill(tid, 0) is supposed to check if tid exists, but it does crash...

No, I don't suggest to remove it, it is useful.
As for the crashes, with glibc pthread_t is really a pointer, so
there's no way to check its validity beforehand. Even if we did check
the thread ID against the list of Python-created threads IDs (stored
in Thread._ident), this could still crash, because the ID becomes
invalid as soon as the thread terminates (all threads are started
detached). Furthermore, this wouldn't work for non-Python created
threads.

> We cannot use the same name for two different C function. One expects a process identifier, whereas the other expects a thread identifier! If Python is compiled without thread, the thread will not exist (as some modules and many other functions).
>

I know, that's why I said "different API": but I must admit it was
poorly worded ;-)
However, this wouldn't solve this particular problem: as long as we
expose sched_setaffinity(), it will crash as soon as someone passes
`0` or getpid() as PID.

>> pthread_setaffinity_np() is really non-portable
>> (it's guarded by __USE_GNU in my system's header)
>
> We can check it in configure. We already use some functions which are GNU extensions, like makedev(). Oh, os.makedev() availability is just not documented :-)

As I said, this wouldn't solve this problem. If someone deems it
necessary, we can open another issue for this feature request.

>> sched_setaffinity() seems to work fine on most systems
>> even when linked with pthread
>
> Again, it looks like a libc/kernel bug. I don't think that Python can work around such issue.
>

Agreed.

> I don't know or need (), but the difference between sched_setaffinity and pthread_getaffinity_np is the same between sigprocmask() and pthread_sigmask(). I chose to expose only the later because the behaviour of sigprocmask is undefined in a process using threads.

Exactly.
However, nothing prevents someone from using sigprocmask() in a
multithreaded process, the only difference is that it won't crash
(AFAICT).

So I suggest to:
1) skip the problematic tests on ARM when built with threads to avoid segfaults
2) if someone wants pthread_getaffinity_np(), then we can still open a
separate feature request