[alangmead@boston.com, on special-casing LinuxThreads]
I might be willing to try my hand at this, but I could use a tiny bit of guidance. (If you don't mind.)
I don't mind <wink>, but I haven't run on Linux since 1994, and have lost track of how Unixish special-casing is done in Python since then. Best advice is to start with a bug report on Python's bug tracker, and perhaps a msg to mailto:python-dev@python.org I think Martin v. Löwis is currently most knowledgeable about messy config issues in Python.
It seems that the patch should only be activated for LinuxThreads, and should be tested for in configure.
Sounds plausible, but I wouldn't know.
Is it reasonable to test for a LinuxThreads specific function (like pthread_kill_other_threads_np). Should I create a functional test that test tries to cause the LinuxThread specific behavior (cause a deadlock) and the notice the problem and fix it.Should I use the glibc feature "getconf GNU_LIBPTHREAD_VERSION"?
I don't know what's available in LinuxThreads *to* test. Most packages have some God-awful preprocessor #define to key off of. Also don't know whether the specific breakage at issue here is unique to LinuxThreads.
The first is easiest to test for, but seems a little error prone. (what if someone else adds the non-standard function in order to ease porting from Linux? What if someone comes up with a LinuxThreads update that solves this problem?) Its testing a feature that is related to the feature I want info for, but not the troublesome behavior itself.
I expect that's why most people settle for testing a package-specific #define. It's also why there's always at least some resistance to patches that do key off goofy symbols: the #ifdef'ed code will probably remain there forever, regardless of whether the problem still exists. So:
The second solution seems to be one step away from the halting problem (although it might be able to be done with "block signal_a, send signal_a, send signal_b, if signal_b is caught but not signal_a, then signals are not rerouted across threads.)
An autoconf-able test that checks for the actual bad behavior would be best. ...
Is it reasonable to put a LinuxThreads specific replacement SET_THREAD_SIGMASK in thread_pthread.h?
Yes.
There are already a slew of system specific defines, and the differences don't seem extreme enough to make a separate thread_linuxthreads.h
Fully agreed. LinuxThreads is primarily pthreads with a bug. That makes it qualitatively the same as all other pthreads implementations <wink>.