> as noted by Victor, it's really easy to crash the interpreter
> by passing an invalid thread ID, which IMHO, should be avoided
> at all cost

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...

> to be safe, we would need to have a different API depending
> on whether Python is built with threads or not
> (i.e. sched_setaffinity() without threads,
> and pthread_setaffinity_np())

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).

> 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 :-)

> 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.

> I don't care strongly about using pthread_getaffinity_np()

I don't really care of pthread_getaffinity_np() :-) To add a new function, we need a usecase and it should be requested. This issue is about a crash using sched_setaffinity(), not about pthread_getaffinity_np.

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. sched_setaffinity manual contains the sentence "If you are using the POSIX threads API, then use pthread_setaffinity_np(3) instead of sched_setaffinity()".

See also Portable Hardware Locality (hwloc):
http://www.open-mpi.org/projects/hwloc/